Release v1.1.0 rc1

[sajayantony]

Draft PR to show version bumps so the release can be PR driven.

The proposal here is to tag 32bfb87 as v1.1.0-rc1

Basically move voting to the PR rather than an issue - #1002

[qweeah]

One question on this: if this PR is merged, then a new commit will be added. We should tag the new commit for releasing. 32bfb87 will not be the target commit.

[qweeah]

ORAS applies the practice of linear commit history, which means a PR will always be merged via squashing or rebasing. This is different from how the version control is done in OCI image spec repo because when a PR is merged, the commit digest might be recalculated and changed. So, in ORAS CLI repo we cannot use PR voting facilities to vote for releasing.

[qweeah]

@sajayantony We already have extra build time data here, the full version is <Version>+<BuildMetadata>
e.g.

• if you build from this commit, the full version string will be 1.1.0-rc1+dev+unreleased.
• Without this code change in this PR, the full version string will be 1.1.0-rc.1+unreleased, the latter already implies the former with less duplicated info.

[shizhMSFT]

Definition quotes from SemVer 2.0.0:

10. Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3----117B344092BD.

[sajayantony]

@shizhMSFT should we up the version then?

[qweeah]

The version for this release is already updated in 42650e5 before the branch cut. @sajayantony Are you suggesting we should do the version update for the next release version? We don't have a procedure for that and might be worth doing after releasing.

[shizhMSFT]

Let's reset the releasing pipeline of v1.1.0-rc.1.

[shizhMSFT]

See details in #1013

[sajayantony]

One question on this: if this PR is merged, then a new commit will be added. We should tag the new commit for releasing. 32bfb87 will not be the target commit.

This is just to show how to get the approval on the PR but keep the code moving forward.
for e.g. the code should probably now move to RC2+ something. This should be merged and not squashed as an example. Again this is not blocking for the current release but I would like to update the release process to PR based either way.
Maybe for the next RC and also update the release docs.

[qweeah]

I think there is a gap. You may have observed that the target commit digest in the voting issue for 1.1.0-rc.1 has been changed after I called for voting. The back-and-forth change happens not because of how we perform release branch cut, but because we want to bump oras-go to include two bug fixes into the release branch after vote call. If we use a vote PR for the cut and want to include new changes after raising the vote PR, we still need to rebase and update the target commit digest and call for vote again. So basically, both ways of calling for vote require re-vote if we want to include new changes into the release branch cut.

Also, the current way of releasing won't block coding. New changes can be merged into the main branch. But if we use a vote PR for release branch cut, other PRs cannot be merged before the vote PR is merged.

[TerryHowe]

I thought the plan was to use the rc.1 version. Close?

[qweeah]

Had a discussion offline with Shiwei and we decided to try this release method. I will raise a PR to revert version update and another one to vote for branch cutting.

[qweeah]

closing as it's already experimented in #1016