I'd like to add one point around IDE integration / debug ability. I notice that I had to choose JDK 8 when I want to run or debug some test with IntelliJ. JDK 11 and JDK 17 just wouldn't work, saying it is missing sun.misc.Signal when IDEA is compiling.
I vaguely remember it used to work for me when using JDK 11 but somehow doesn't work for me lately. I'm not sure if anyone else is experiencing the same issue? Or is it just a cache/config issue on my side. -Siyao On Mon, Feb 9, 2026 at 9:48 AM Ethan Rose <[email protected]> wrote: > > 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] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
