notaryproject / notation-go

A collection of libraries for supporting sign and verify OCI artifacts. Based on Notary Project specifications.
Apache License 2.0
31 stars 41 forks source link

vote: v1.1.1 #408

Closed JeyJeyGao closed 1 month ago

JeyJeyGao commented 1 month ago

Release

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

[!Note] This release doesn't include the #379 as this is a patch release.

The commit 8d3b7a22a70a7d0e5e71f4f717ccbb03eb9ae59e 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 #379, starting from 1752918878aca0f5f811263be091cdd17a26562a and ending with 254dfcde664212784c8116200efb97e17b30683d, 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: https://github.com/notaryproject/notation-go/compare/v1.1.0...8d3b7a22a70a7d0e5e71f4f717ccbb03eb9ae59e

Two-Hearts commented 1 month ago

LGTM

JeyJeyGao commented 1 month ago

LGTM

shizhMSFT commented 1 month ago

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 #379.
  5. Close this issue and create a new issue to vote on the latest commit of the release-1.1 branch
JeyJeyGao commented 1 month ago

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 commented 1 month ago

LGTM

JeyJeyGao commented 1 month ago

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