Yes actually we should include HDDS-11040 since it fixes a compatibility regression in 1.4.0. Thanks Attila!
What should I do specifically, could we update this part in the document? > We need to cherry pick this commit <https://github.com/apache/ozone/commit/4399cc4be89a09a63cac255f0747db5e96aed2bd> back to the master branch after the 1.4.1 release goes out to make sure that future releases from master are compatible with these proto changes. The current instructions in the document are to do protolock and version update on master before cutting a minor release branch. Usually we would not have proto changes in a patch release and the extra copy would not be necessary. 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. > New branches would be for major and minor releases (first two semver digits) but not patch releases like this one since they are just cherry picks. This is something that can also be clarified in the doc. > We can also add relevant steps before "push the release candidate tag to > github" in our documentation. > Yes good point. It looks like if followed exactly the doc will instruct you to push the tag but not the branch. This may cause them to diverge in the remote if changes like version bumps were done to the branch locally instead of with PRs. What I need to do before continuing the ozone-1.4.1 RC0 release process? > Yes the steps you listed here look good. Once the release goes out I'll update the release manager doc with all our findings and we can review it. Thanks Ethan On Tue, Aug 13, 2024 at 10:05 AM Attila Doroszlai <adorosz...@apache.org> wrote: > Thanks Xi Chen for working on the release. > > Can we also include HDDS-11040? > > -Attila > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ozone.apache.org > For additional commands, e-mail: dev-h...@ozone.apache.org > >
