You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As documented in Release checklist, we need to update the oras version to the upcoming release version before voting as oras maintains a linear commit history. However, there is a risk that we might need to revert the version update commit if the vote gets rejected.
Success scenario:
gitGraph
commit tag: "v1.0.0"
commit
commit id: "bump: update to v1.1.0-rc.1" tag: "v1.1.0-rc.1" type: HIGHLIGHT
branch release-1.1
checkout main
commit
commit id: "fix: fix a bug"
commit
checkout release-1.1
cherry-pick id: "fix: fix a bug"
commit id: "bump: update to v1.1.0-rc.2" tag: "v1.1.0-rc.2" type: HIGHLIGHT
checkout main
cherry-pick id: "bump: update to v1.1.0-rc.2"
checkout release-1.1
commit id: "bump: update to v1.1.0" tag: "v1.1.0" type: HIGHLIGHT
checkout main
cherry-pick id: "bump: update to v1.1.0"
commit
Loading
Bad scenario where releasing v1.1.0-rc.1 is rejected once:
As inspired by opencontainers/image-spec, #1002 and #1010, the above risk can be mitigated by cutting from a PR branch (and then merge back) where the PR approval is treated as a vote although it makes oras commit history non-linear.
Success scenario:
%%{init: { 'theme': 'base' } }%%
gitGraph
commit tag: "v1.0.0"
commit
branch fork/release-vote
commit id: "bump: update to v1.1.0-rc.1" tag: "v1.1.0-rc.1" type: HIGHLIGHT
branch release-1.1
checkout main
merge fork/release-vote
commit
commit id: "fix: fix a bug"
commit
checkout release-1.1
cherry-pick id: "fix: fix a bug"
branch fork/release-vote-2
commit id: "bump: update to v1.1.0-rc.2" tag: "v1.1.0-rc.2" type: HIGHLIGHT
checkout release-1.1
merge fork/release-vote-2
checkout main
cherry-pick id: "bump: update to v1.1.0-rc.2"
checkout release-1.1
branch fork/release-vote-3
commit id: "bump: update to v1.1.0" tag: "v1.1.0" type: HIGHLIGHT
checkout release-1.1
merge fork/release-vote-3
checkout main
cherry-pick id: "bump: update to v1.1.0"
commit
Loading
Bad scenario where releasing v1.1.0-rc.1 is rejected once:
@qweeah@TerryHowe@sajayantony@SteveLasker I think we can reset releasing v1.1.0-rc.1 and start experimenting with the new approach. If it works perfect, we can update the release checklist accordingly.
As documented in Release checklist, we need to update the oras version to the upcoming release version before voting as
orasmaintains a linear commit history. However, there is a risk that we might need to revert the version update commit if the vote gets rejected.Success scenario:
Bad scenario where releasing
v1.1.0-rc.1is rejected once:As inspired by opencontainers/image-spec, #1002 and #1010, the above risk can be mitigated by cutting from a PR branch (and then merge back) where the PR approval is treated as a vote although it makes
orascommit history non-linear.Success scenario:
%%{init: { 'theme': 'base' } }%% gitGraph commit tag: "v1.0.0" commit branch fork/release-vote commit id: "bump: update to v1.1.0-rc.1" tag: "v1.1.0-rc.1" type: HIGHLIGHT branch release-1.1 checkout main merge fork/release-vote commit commit id: "fix: fix a bug" commit checkout release-1.1 cherry-pick id: "fix: fix a bug" branch fork/release-vote-2 commit id: "bump: update to v1.1.0-rc.2" tag: "v1.1.0-rc.2" type: HIGHLIGHT checkout release-1.1 merge fork/release-vote-2 checkout main cherry-pick id: "bump: update to v1.1.0-rc.2" checkout release-1.1 branch fork/release-vote-3 commit id: "bump: update to v1.1.0" tag: "v1.1.0" type: HIGHLIGHT checkout release-1.1 merge fork/release-vote-3 checkout main cherry-pick id: "bump: update to v1.1.0" commitBad scenario where releasing
v1.1.0-rc.1is rejected once:%%{init: { 'theme': 'base' } }%% gitGraph commit tag: "v1.0.0" commit branch fork/release-vote commit id: "bump: update to v1.1.0-rc.1" checkout main commit commit commit id: "fix: address vote comments" branch fork/release-vote-2 commit id: "bump: update to v1.1.0-rc.1 again" tag: "v1.1.0-rc.1" type: HIGHLIGHT checkout main merge fork/release-vote-2 commit@qweeah @TerryHowe @sajayantony @SteveLasker I think we can reset releasing
v1.1.0-rc.1and start experimenting with the new approach. If it works perfect, we can update the release checklist accordingly.