> Suppose we create a new ozone-2.x branch. We may treat it in a similar way as the ozone-2.1 branch. Just don't merge anything until we have decided to roll a new release.
What does this look like in practice? For the average PR, what branch(es) does it go into? How do we track changes for each release? If you're describing backporting selective fixes for a 2.2.0 release then you're actually describing a 2.1.1 release which is already handled by our current branching model. > We probably should focus on the users of Ozone. Take the current JDK 17 issue discussed in this email thread as an example -- some organizations have to get the CVE fixed but some other organizations may not be able to update JDK. How would the current branch practices fit all their needs? I'm fine with doing a 3.0 release in the near future if there is demand for it. It would be good to line it up with ZDU as well. My point is not that the next release should be 2.2.0 instead of 3.0.0, it is that we cannot develop 2.2.0 and 3.0.0 in parallel without adding significant burden to developers, which I don't think is necessary. > BTW, this synchronized approach may be the reason that the time between Ozone releases is oftenly very long. The synchronization model is that patch releases for any supported line can be done in parallel with the next major or minor release. 3.0.0 and 2.1.1 can be released in any order, but releasing 3.0.0 and then retroactively releasing 2.2.0 does not make sense, therefore they are synchronized. I think the confusion here is that you seem to be describing a 2.2.0 release that is actually built like a 2.1.1 release. That 2.1.1 release can happen at any time. I think we should leave 2.2.0 to be the next release being tracked by master. We are targeting the completion of ZDU in the next few months, and once that is merged it would make sense to cut a 3.0.0 with ZDU and JDK17 minimum server version. Ethan On Wed, Feb 4, 2026 at 9:12 PM Tsz-Wo Nicholas Sze <[email protected]> wrote: > Hi Ethan, > > > Anytime we create a new branch we need to manage what commits should go > into it and why. ... > > Suppose we create a new ozone-2.x branch. We may treat it in a similar way > as the ozone-2.1 branch. Just don't merge anything until we have decided > to roll a new release. > > > ... With our current branch practices (which I think are still the > optimal way to > proceed), any changes targeting 3.0 should be suspended until we decide > that is the next release and update our POM file in master accordingly. ... > > We probably should focus on the users of Ozone. Take the current JDK 17 > issue discussed in this email thread as an example -- some organizations > have to get the CVE fixed but some other organizations may not be able to > update JDK. How would the current branch practices fit all their needs? > > BTW, this synchronized approach may be the reason that the time between > Ozone releases is oftenly very long. > > Tsz-Wo > > > On Wed, Feb 4, 2026 at 1:12 PM Ethan Rose <[email protected]> wrote: > > > Hi Tsz-Wo > > > > Anytime we create a new branch we need to manage what commits should go > > into it and why. We currently do this in a very simple way where master > > tracks the next release indicated by the POM version > > < > > > https://github.com/apache/ozone/blob/d71ab1f3303fb2238c1791fc15d56ab21202bb96/hadoop-hdds/common/pom.xml#L20 > > >, > > and each major/minor version has a branch cut once its release process > > starts. From there, all patch releases are made by cherry-picking changes > > onto those existing release branches, and git tags point to the commits > > that definitively correspond to releases from those branches. > > > > The POM indicates that the next release we are targeting is 2.2.0, and > > therefore all commits landing in master will be going to that release. > The > > ozone-2.1 branch is for backporting fixes from master if we need to > create > > a 2.1.1 patch release. > > > > If we are going to track a 2.2.0 and 3.0.0 release at the same time, then > > almost all commits except those exclusive to 3.0 need to be merged into > two > > different branches, which is where management becomes difficult. With our > > current branch practices (which I think are still the optimal way to > > proceed), any changes targeting 3.0 should be suspended until we decide > > that is the next release and update our POM file in master accordingly. > > Jira's target version field can be used to track such changes. > > > > Ethan > > > > On Mon, Feb 2, 2026 at 4:33 PM Tsz Wo Sze <[email protected]> wrote: > > > > > Hi Ethan, > > > > > > Thanks for pointing out the ozone-2.1 branch! For bug fix versions for > > 2.0 > > > and 2.1, it should be okay. > > > > > > Note that ozone-2.1 is 18 commits ahead of and 470 commits behind > master. > > > If we don't have a plan to release 2.2 from master, then it is fine not > > > having a new branch. BTW, we probably don't have to manage anything > for > > > just creating a branch? > > > > > > Tsz-Wo > > > > > > > > > > > > On Mon, Feb 2, 2026 at 7:30 AM Ethan Rose <[email protected]> wrote: > > > > > > > Hi Tsz-Wo, we have the ozone-2.1 branch to backport fixes for the > next > > > > patch release in the 2.x line, while master will track the next > release > > > > according to the SNAPSHOT version in the POM. Do you think we need > > > another > > > > branch? Seems like it will be harder to manage. > > > > > > > > Ethan > > > > > > > > On Sun, Feb 1, 2026 at 12:45 PM Tsz Wo Sze <[email protected]> > > wrote: > > > > > > > > > Hi Attila and others, > > > > > > > > > > > With 2.0 and 2.1 out, I guess we should make this change in 3.0. > > > > > I agree that the JDK change should be in 3.0. > > > > > > > > > > We should also take this chance to update the protos to protobuf 3. > > > > > - e.g. https://issues.apache.org/jira/browse/HDDS-10481 > > > > > > > > > > Also, we probably should create branch-2 from the master branch? > > > > > Otherwise, it may become very hard to release bug fix versions for > > 2.0 > > > > and > > > > > 2.1. > > > > > > > > > > Tsz-Wo > > > > > > > > > > > > > > > > > > > > On Thu, Jan 29, 2026 at 3:18 AM Attila Doroszlai < > > > [email protected]> > > > > > wrote: > > > > > > > > > > > > To continue receiving fixes for these dependencies, we would > need > > > to > > > > > > > bump the minimum Java required for building Ozone. We would > also > > > > > > > require the same version for running server components. Client > > > > > > > components should still be usable with Java 8. > > > > > > > > > > > > Pull request for bumping server-side Java to 17: > > > > > > https://github.com/apache/ozone/pull/9640 > > > > > > > > > > > > > I think the next major version, 2.0 would be a good candidate > to > > > make > > > > > > > such a move. We should continue to support Java 8 with 1.4.x. > > > > > > > > > > > > With 2.0 and 2.1 out, I guess we should make this change in 3.0. > > > > > > > > > > > > -Attila > > > > > > > > > > > > full thread: > > > > > > https://lists.apache.org/thread/k9kvobrg7ybthjfs78rfscpc2lty5x5y > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > >
