Hi Xi Chen, sorry for not getting back to this earlier. The proto changes going out in the patch release are ok this time since there has not been another major release yet. In general this will not always be the case which is why backporting proto changes should be avoided. For example if 1.5.0 went out with one set of changes, then we released 1.4.2 and 1.5.1 later with a patch containing proto changes that were not in 1.5.0 then 1.4.2 upgrade to 1.5.0 may no longer be compatible. It could be seen as a “downgrade” in the proto spec that removes fields, even though it is an Ozone version upgrade. In this specific case it should be fine though, we just need to copy the new lockfiles back to master after the release.
The GPG key has not been officially published to the release area, it is still in dev. We need it in release before this release goes out so people can verify the signatures from the official location. Yiyang’s key (the previous release manager) is in the release KEYS file but not in the dev KEYS file, so moving the current dev would erase it. If you add your key on top of the latest KEYS file in release as specified in the release guide <https://ozone-site-v2.staged.apache.org/docs/developer-guide/project/release-guide#publish-your-gpg-key> and push that to dev I can do the final move to get it to release. The release guide <https://ozone-site-v2.staged.apache.org/docs/developer-guide/project/release-guide#vote> does actually say to share the dev keys file in the vote mail which is a mistake. I can update this as well. This doesn’t affect the content of the current RC. I think the current branch structure in GitHub is not quite right. There is an ozone-1.4 branch <https://github.com/apache/ozone/commits/ozone-1.4/> and an ozone-1.4.1 branch <https://github.com/apache/ozone/commits/ozone-1.4.1> but they both point to the same commit. Since patch releases should just be cherry picks, we shouldn’t need a branch for ozone-1.4.1 and it could actually cause future patch releases on the 1.4 line to diverge if cherry picks are done there but not to ozone-1.4. The branch name will also conflict with the final ozone-1.4.1 tag that will be applied to the release commit and cause confusion. I suggest deleting the ozone-1.4.1 branch. This also does not affect the current RC. The ozone-1.4.1-RC0 tag <https://github.com/apache/ozone/commits/ozone-1.4.1-RC0/> is pointing to two commits that are after the ozone-1.4 and ozone-1.4.1 branches. This gives the message: “This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository” when the hash of the release is viewed in GitHub. Each patch release tag and RC should point to the last commit on the ozone-1.4 branch at that time, so for the next patch release on this line, more commits can be added to the branch but the tag would remain in place. To fix this, we can fast-forward the ozone-1.4 branch to include these commits, which should not change the hash of the current RC. The RC itself looks good to me: - Built from source. - Verified signatures against dev keys file (Will check again when we have it in the release area) - Verified checksums - Verified docs are included in the build and work in Chrome. - Verified output from ozone version - Tested ozone freon ockrw in docker. I’m +1 on this release candidate, thanks for working on it! I think we just have a few minor steps to do before shipping it out. I’m also working on a PR to update the release guide in the new website for handling regular patch releases. The current docs for that section assume the patch release is for a CVE or critical bug and do not exactly translate to a normal maintenance release. Ethan On Mon, Aug 12, 2024 at 9:57 AM Xi Chen <che...@apache.org> wrote: > Hi Sammi, > > thanks for checking. > For your question: > Q: Have you pushed the artifacts to the apache Nexus? If so, could you > share the link? > A: Yes, I have pushed the artifacts to apache Nexus, the link is provided > in the email: > - Maven artifacts are staged at: > - > https://repository.apache.org/content/repositories/orgapacheozone-1023/ > > Thanks, > Xi Chen > > On 2024/08/12 10:11:36 Sammi Chen wrote: > > Xi, > > > > Thanks for leading the effort of a new release. Have you pushed the > > artifacts to the apache Nexus? If so, could you share the link? > > > > > > Thanks, > > Sammi > > > > On Tue, 6 Aug 2024 at 16:45, mrchenx <mrch...@126.com> wrote: > > > > > Dear Ozone Devs, > > > We have released 1.4.0 on Jan 19th. Now there are 169 new commits > > > already landed on 1.4.1 branch, Includes Ratis upgrade (upgrade to > Ratis > > > 3.1.0), some bug fixes, as well as performance optimizations, and some > > > necessary dependencies. I am calling for a vote on Apache Ozone > 1.4.1 > > > RC0. - The RC0 tag can be found on Github at: > > > - https://github.com/apache/ozone/releases/tag/ozone-1.4.1-RC0 > > > - 169 Jiras were cherry-pick for ozone-1.4.1 > > > - > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20HDDS%20AND%20fixVersion%20%3D%201.4.1 > > > - The source and binary tarballs can be found at: > > > - https://dist.apache.org/repos/dist/dev/ozone/1.4.1-rc0/ > > > - Maven artifacts are staged at: > > > - > > > > https://repository.apache.org/content/repositories/orgapacheozone-1023/ > > > - The public key used to sign the artifacts can be found at: > > > - https://dist.apache.org/repos/dist/dev/ozone/KEYS > > > - The fingerprint of the key used to sign the artifacts is: > > > - 0D8C19F5514E2786007936F758C87003FF9A1A38 > > > The vote will run for 7 days, ending on Aug 13th 2024 at 16:45 pm > UTC+8. > > > > > > Thanks > > > > > > Xi Chen > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org > For additional commands, e-mail: dev-h...@ozone.apache.org > >
