Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Experimenting New Release Process #1013

Closed
shizhMSFT opened this issue Jul 9, 2023 · 10 comments
Closed

Experimenting New Release Process #1013

shizhMSFT opened this issue Jul 9, 2023 · 10 comments
Assignees
@TerryHowe @sajayantony @qweeah @SteveLasker

Comments

@shizhMSFT
Copy link
Contributor

shizhMSFT commented Jul 9, 2023 •
edited
Loading

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:

gitGraph
  commit tag: "v1.0.0"
  commit
  commit id: "bump: update to v1.1.0-rc.1"
  commit
  commit id: "revert: bump: update to v1.1.0-rc.1" type: REVERSE
  commit
  commit id: "fix: address vote comments"
  commit id: "bump: update to v1.1.0-rc.1 again" tag: "v1.1.0-rc.1" type: HIGHLIGHT
  commit
Loading

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:

%%{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
Loading

@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.
@shizhMSFT
Copy link
Contributor Author

Since the commit history of the new approach is non-linear but GitHub shows the non-linear commits in a linear way, PR reviewers are required to be careful about the following situation where feat: A is before the v1.1.0-rc.1 (in terms of commit time) but not included in v1.1.0-rc.1 (as they are in different branches).

%%{init: { 'theme': 'base' } }%%
gitGraph
  commit tag: "v1.0.0"
  commit
  branch fork/release-vote
  checkout main
  commit id: "feat: A"
  checkout fork/release-vote
  commit id: "bump: update to v1.1.0-rc.1" tag: "v1.1.0-rc.1" type: HIGHLIGHT
  checkout main
  commit id: "feat: B"
  merge fork/release-vote
  checkout main
  commit
Loading

@shizhMSFT
Copy link
Contributor Author

shizhMSFT commented Jul 9, 2023 •
edited
Loading

/cc @FeynmanZhou @yizha1 as notation may also adopt this approach.

@shizhMSFT shizhMSFT mentioned this issue Jul 9, 2023
Closed
@qweeah
Copy link
Contributor

qweeah commented Jul 10, 2023 •
edited
Loading

Since the commit history of the new approach is non-linear but GitHub shows the non-linear commits in a linear way, PR reviewers are required to be careful about the following situation where feat: A is before the v1.1.0-rc.1 (in terms of commit time) but not included in v1.1.0-rc.1 (as they are in different branches).

%%{init: { 'theme': 'base' } }%%
gitGraph
  commit tag: "v1.0.0"
  commit
  branch fork/release-vote
  checkout main
  commit id: "feat: A"
  checkout fork/release-vote
  commit id: "bump: update to v1.1.0-rc.1" tag: "v1.1.0-rc.1" type: HIGHLIGHT
  checkout main
  commit id: "feat: B"
  merge fork/release-vote
  checkout main
  commit
Loading

How can we deal with this situation? If we cannot pick feat: A and feat: B out, should we disallow code merge into main branch until cutting from a PR branch is done?

Update: This is not an issue. I realized that the v1.1.0-rc.1 doesn't include feat: A and feat: B, so voting for branch cutting won't block merging new codes.

@shizhMSFT
Copy link
Contributor Author

shizhMSFT commented Jul 10, 2023 •
edited
Loading

As alternative solution to cherry picking, we can merge main in the release branch if all new commits should be included, and then merge back.

Cherry pick version:

%%{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 id: "fix: fix a bug"
  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

Merge version

%%{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 id: "fix: fix a bug"
  checkout release-1.1
  merge main
  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
  merge release-1.1
  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
  merge release-1.1
  commit
Loading

@qweeah qweeah mentioned this issue Jul 10, 2023
Open
@shizhMSFT shizhMSFT mentioned this issue Jul 10, 2023
Merged
@sajayantony
Copy link
Contributor

Do we need to update - https://github.com/oras-project/oras-www/blob/main/docs/community/developer_guide.mdx#L79
Honestly I haven't found non-linear merge an issue as long as the person knows that the release commit always must merged and not squashed.

Another recommendation would be to include the diff from the last tag (major or minor)
v1.0.0...v1.1.0-rc.1

❯ git log --pretty --graph --oneline -n7
* 21d0b71c (HEAD -> main, upstream/main) test: add unit test for error scenario in `internal/credential/store.go` (#982)
* ed3fbcc1 chore: update container build prepare job output in Github Actions (#1019)
* 46780e70 chore: fix the links in project readme (#1012)
* 5194c2ec (origin/main, origin/HEAD, release_v1.1.0-rc1) chore: fix lint warning (#1001)
*   ef6e0222 bump: tag and release ORAS CLI v1.1.0-rc.1 (#1016)
|\
| * edfc253f (tag: v1.1.0-rc.1, upstream/release-1.1) bump: update oras version to 1.1.0-rc.1
|/
* 57c63b84 bump: update golang from 1.20.2 to 1.20.5 (#1015)

@qweeah
Copy link
Contributor

qweeah commented Jul 13, 2023

@sajayantony I am on it oras-project/oras-www#213

@github-actions
Copy link

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

@github-actions github-actions bot added the stale Inactive issues or pull requests label Sep 12, 2023
@TerryHowe TerryHowe removed the stale Inactive issues or pull requests label Sep 12, 2023
@github-actions GitHub Actions
Copy link

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

@github-actions github-actions bot added the stale Inactive issues or pull requests label Nov 12, 2023
@TerryHowe TerryHowe removed the stale Inactive issues or pull requests label Nov 13, 2023
@TerryHowe
Copy link
Member

Do we need this?

@qweeah
Copy link
Contributor

qweeah commented Nov 14, 2023

This is already applied and documented in here

@qweeah qweeah closed this as completed Nov 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@TerryHowe TerryHowe

@sajayantony sajayantony

@qweeah qweeah

@SteveLasker SteveLasker

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@TerryHowe @sajayantony @qweeah @SteveLasker @shizhMSFT