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] > > > > > > > > > > > > > > > > > > > >
