Hi Ethan, thanks for your replies. > In this specific case it should be fine though, we just need to copy the new > lockfiles back to master after the release. What should I do specifically, could we update this part in the document?
> The GPG key has not been officially published to the release area, ... > Yiyang’s key (theprevious release manager) is in the release KEYS file but > not in the dev KEYS file. I have updated the dev KEYS file, and Yiyang has helped me move the KEYs to the release directory. > I think the current branch structure in GitHub is not quite right. So we only need a tag of ozone-1.4.1 instead of a branch of 1.4.1, right? New branches are only needed for major releases, but not for minor releases. > <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. I actually followed https://ozone-site-v2.staged.apache.org/docs/developer-guide/project/release-guide/#push-the-release-candidate-tag-to-github to push the tag to the remote. I will push the latest two commits to the ozone-1.4 branch. We can also add relevant steps before "push the release candidate tag to github" in our documentation. What I need to do before continuing the ozone-1.4.1 RC0 release process? - Delete the ozone-1.4.1 branch (https://github.com/apache/ozone/commits/ozone-1.4.1) - Push the latest two commits of the ozone-1.4.1-RC0 tag to the ozone-1.4 branch (https://github.com/apache/ozone/commits/ozone-1.4) Xi Chen On 2024/08/12 21:48:25 Ethan Rose wrote: > 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 > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org For additional commands, e-mail: dev-h...@ozone.apache.org
