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.

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

vote: v1.1.1 #408

Closed
2 of 6 tasks
JeyJeyGao opened this issue May 29, 2024 · 6 comments
Closed
2 of 6 tasks

vote: v1.1.1 #408

JeyJeyGao opened this issue May 29, 2024 · 6 comments

Comments

@JeyJeyGao
Copy link
Contributor

JeyJeyGao commented May 29, 2024

Release

This would mean tagging 8d3b7a2 as v1.1.1 to release.

Note

This release doesn't include the #379 as this is a patch release.

The commit 8d3b7a2 was generated by the following steps:

  1. Checked out a new branch: git checkout -b release-1.1 v1.1.0
  2. Cherry-picked all commits from the main branch, excluding feat: add support for signing blob #379, starting from 1752918 and ending with 254dfcd, totaling 23 commits. Conflicts were also resolved.
  3. Pushed to origin as the release-1.1 branch.

Vote

We need at least 4 approvals from 6 maintainers to release notation-go v1.1.1.

Changes

The code changes compared to v1.1.0 include:

Full Changelog: v1.1.0...8d3b7a2

@Two-Hearts
Copy link
Contributor

LGTM

1 similar comment
@JeyJeyGao
Copy link
Contributor Author

LGTM

@shizhMSFT
Copy link
Contributor

I have concerns about the process of generating the release-1.1 branch since the hashes of all commits after v1.1.0 are changed without proper reviews. Meanwhile, there is no proof that the resulted head of the branch release-1.1 passes all the checks we set for the main branch.

Therefore, I'd like to propose a more compliant way to generate the release-1.1 branch.

  1. Delete the existing release-1.1 branch
  2. Update build.yml, codeql.yml, and license-checker.yml in the main branch to include release-* (see samples)
  3. Set a branch protection rule for release-* with the same settings as main.
  4. Checkout release-1.1 based on main. Send a PR to release-1.1 to revert feat: add support for signing blob #379.
  5. Close this issue and create a new issue to vote on the latest commit of the release-1.1 branch

@JeyJeyGao
Copy link
Contributor Author

I have concerns about the process of generating the release-1.1 branch since the hashes of all commits after v1.1.0 are changed without proper reviews. Meanwhile, there is no proof that the resulted head of the branch release-1.1 passes all the checks we set for the main branch.

Therefore, I'd like to propose a more compliant way to generate the release-1.1 branch.

  1. Delete the existing release-1.1 branch
  2. Update build.yml, codeql.yml, and license-checker.yml in the main branch to include release-* (see samples)
  3. Set a branch protection rule for release-* with the same settings as main.
  4. Checkout release-1.1 based on main. Send a PR to release-1.1 to revert feat: add support for signing blob #379.
  5. Close this issue and create a new issue to vote on the latest commit of the release-1.1 branch

@priteshbandi How about this: instead of cherry-picking each commit, we just revert #379 in release-1.1 branch?

priteshbandi pushed a commit that referenced this issue May 30, 2024
To enable a safe way to create a release branch, we need to enable CI for the release branch as proposed in #408

Signed-off-by: Junjie Gao <junjiegao@microsoft.com>
@priteshbandi
Copy link
Contributor

LGTM

@JeyJeyGao
Copy link
Contributor Author

I will create a new release vote based on the proposed steps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

4 participants