You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ozone.apache.org by Attila Doroszlai <ad...@apache.org> on 2024/11/15 20:55:52 UTC
[DISCUSS] bump minimum required Java
Hi Apache Ozone community,
Ozone currently requires minimum Java 8 at both build and run time,
but it compiles and runs fine with newer Java versions. The GitHub CI
workflow includes compilation with Java 11, 17 and 21. Tests are run
with Java 17.
Java 21 has been GA for more than a year, Java 17 for 3 years now. [1]
Some third-party dependencies have stopped releasing fixes for
versions that work with Java 8.
- Derby requires Java 21 [2]
- Spring and jOOQ require Java 17 [3], [4]
These are used only by Recon.
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.
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.
What do you think?
-Attila
[1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html
[2] https://db.apache.org/derby/derby_downloads.html
[3] https://docs.spring.io/spring-framework/reference/6.0/overview.html
[4] https://www.jooq.org/download/versions#oss
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
For additional commands, e-mail: dev-help@ozone.apache.org
Re: [DISCUSS] bump minimum required Java
Posted by Wei-Chiu Chuang <we...@apache.org>.
Does it also imply dropping Hadoop2 support?
On Mon, Nov 18, 2024 at 11:38 AM Siyao Meng <si...@apache.org> wrote:
> I am in favor of bumping the minimum JDK. We could also start experimenting
> with ZGC in Java 17.
>
> For Ozone in general, we could change it to require Java 11.
>
>
> @szetszwo@gmail.com <sz...@gmail.com> Is there any particular reason we
> want Java 11? I am leaning towards bumping it to at least Java 17.
>
> Thanks,
> Siyao
>
> On Fri, Nov 15, 2024 at 1:21 PM Tsz Wo Sze <sz...@gmail.com> wrote:
>
> > Hi Attila,
> >
> > Thanks for starting the discussion! Could it be that only Recon requires
> > Java 21? For Ozone in general, we could change it to require Java 11.
> >
> > Tsz-Wo
> >
> >
> > On Fri, Nov 15, 2024 at 12:56 PM Attila Doroszlai <adoroszlai@apache.org
> >
> > wrote:
> >
> > > Hi Apache Ozone community,
> > >
> > > Ozone currently requires minimum Java 8 at both build and run time,
> > > but it compiles and runs fine with newer Java versions. The GitHub CI
> > > workflow includes compilation with Java 11, 17 and 21. Tests are run
> > > with Java 17.
> > >
> > > Java 21 has been GA for more than a year, Java 17 for 3 years now. [1]
> > >
> > > Some third-party dependencies have stopped releasing fixes for
> > > versions that work with Java 8.
> > > - Derby requires Java 21 [2]
> > > - Spring and jOOQ require Java 17 [3], [4]
> > >
> > > These are used only by Recon.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > What do you think?
> > >
> > > -Attila
> > >
> > > [1]
> > https://www.oracle.com/java/technologies/java-se-support-roadmap.html
> > > [2] https://db.apache.org/derby/derby_downloads.html
> > > [3]
> https://docs.spring.io/spring-framework/reference/6.0/overview.html
> > > [4] https://www.jooq.org/download/versions#oss
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> > > For additional commands, e-mail: dev-help@ozone.apache.org
> > >
> > >
> >
>
Re: [DISCUSS] bump minimum required Java
Posted by Siyao Meng <si...@apache.org>.
I am in favor of bumping the minimum JDK. We could also start experimenting
with ZGC in Java 17.
For Ozone in general, we could change it to require Java 11.
@szetszwo@gmail.com <sz...@gmail.com> Is there any particular reason we
want Java 11? I am leaning towards bumping it to at least Java 17.
Thanks,
Siyao
On Fri, Nov 15, 2024 at 1:21 PM Tsz Wo Sze <sz...@gmail.com> wrote:
> Hi Attila,
>
> Thanks for starting the discussion! Could it be that only Recon requires
> Java 21? For Ozone in general, we could change it to require Java 11.
>
> Tsz-Wo
>
>
> On Fri, Nov 15, 2024 at 12:56 PM Attila Doroszlai <ad...@apache.org>
> wrote:
>
> > Hi Apache Ozone community,
> >
> > Ozone currently requires minimum Java 8 at both build and run time,
> > but it compiles and runs fine with newer Java versions. The GitHub CI
> > workflow includes compilation with Java 11, 17 and 21. Tests are run
> > with Java 17.
> >
> > Java 21 has been GA for more than a year, Java 17 for 3 years now. [1]
> >
> > Some third-party dependencies have stopped releasing fixes for
> > versions that work with Java 8.
> > - Derby requires Java 21 [2]
> > - Spring and jOOQ require Java 17 [3], [4]
> >
> > These are used only by Recon.
> >
> > 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.
> >
> > 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.
> >
> > What do you think?
> >
> > -Attila
> >
> > [1]
> https://www.oracle.com/java/technologies/java-se-support-roadmap.html
> > [2] https://db.apache.org/derby/derby_downloads.html
> > [3] https://docs.spring.io/spring-framework/reference/6.0/overview.html
> > [4] https://www.jooq.org/download/versions#oss
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> > For additional commands, e-mail: dev-help@ozone.apache.org
> >
> >
>
Re: [DISCUSS] bump minimum required Java
Posted by Ethan Rose <er...@apache.org>.
+1 for keeping java client compatible with java 8 and increasing server
side minimum java version in Ozone 2.0. As for the specific version
requirements for language, build, and runtime on the server side I'm not
sure I have a strong opinion/enough information to weigh in on specifics
right now.
Ethan
On Mon, Nov 18, 2024 at 4:28 PM Tsz Wo Sze <sz...@gmail.com> wrote:
> > ... Is there any particular reason we want Java 11?
>
> Just want to be more inclusive. Requiring a higher Java version
> may exclude more applications. We could be forcing the dependent projects
> such as HBase to bump their Java version. Not sure if it is true.
>
> > So for these reasons I think making a client/server distinction in the
> Java version requirement would be better, instead of Recon vs. everything
> else.
>
> That's a good point! We should require a lower Java version for
> the client-side. It probably should stay at Java 8.
>
> Tsz-Wo
>
>
> On Mon, Nov 18, 2024 at 12:36 PM Attila Doroszlai <ad...@apache.org>
> wrote:
>
> > > Could it be that only Recon requires Java 21?
> >
> > Yes, technically only Recon (its dependencies) as far as I know. But:
> >
> > - I think it's easier to manage hosts with uniform Java version
> > - we don't know when some other dependency of OM/SCM/etc. starts
> > requiring newer Java
> >
> > So for these reasons I think making a client/server distinction in the
> > Java version requirement would be better, instead of Recon vs.
> > everything else.
> >
> > -Attila
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> > For additional commands, e-mail: dev-help@ozone.apache.org
> >
> >
>
Re: [DISCUSS] bump minimum required Java
Posted by Tsz Wo Sze <sz...@gmail.com>.
> ... Is there any particular reason we want Java 11?
Just want to be more inclusive. Requiring a higher Java version
may exclude more applications. We could be forcing the dependent projects
such as HBase to bump their Java version. Not sure if it is true.
> So for these reasons I think making a client/server distinction in the
Java version requirement would be better, instead of Recon vs. everything
else.
That's a good point! We should require a lower Java version for
the client-side. It probably should stay at Java 8.
Tsz-Wo
On Mon, Nov 18, 2024 at 12:36 PM Attila Doroszlai <ad...@apache.org>
wrote:
> > Could it be that only Recon requires Java 21?
>
> Yes, technically only Recon (its dependencies) as far as I know. But:
>
> - I think it's easier to manage hosts with uniform Java version
> - we don't know when some other dependency of OM/SCM/etc. starts
> requiring newer Java
>
> So for these reasons I think making a client/server distinction in the
> Java version requirement would be better, instead of Recon vs.
> everything else.
>
> -Attila
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> For additional commands, e-mail: dev-help@ozone.apache.org
>
>
Re: [DISCUSS] bump minimum required Java
Posted by Attila Doroszlai <ad...@apache.org>.
> Could it be that only Recon requires Java 21?
Yes, technically only Recon (its dependencies) as far as I know. But:
- I think it's easier to manage hosts with uniform Java version
- we don't know when some other dependency of OM/SCM/etc. starts
requiring newer Java
So for these reasons I think making a client/server distinction in the
Java version requirement would be better, instead of Recon vs.
everything else.
-Attila
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
For additional commands, e-mail: dev-help@ozone.apache.org
Re: [DISCUSS] bump minimum required Java
Posted by Tsz Wo Sze <sz...@gmail.com>.
Hi Attila,
Thanks for starting the discussion! Could it be that only Recon requires
Java 21? For Ozone in general, we could change it to require Java 11.
Tsz-Wo
On Fri, Nov 15, 2024 at 12:56 PM Attila Doroszlai <ad...@apache.org>
wrote:
> Hi Apache Ozone community,
>
> Ozone currently requires minimum Java 8 at both build and run time,
> but it compiles and runs fine with newer Java versions. The GitHub CI
> workflow includes compilation with Java 11, 17 and 21. Tests are run
> with Java 17.
>
> Java 21 has been GA for more than a year, Java 17 for 3 years now. [1]
>
> Some third-party dependencies have stopped releasing fixes for
> versions that work with Java 8.
> - Derby requires Java 21 [2]
> - Spring and jOOQ require Java 17 [3], [4]
>
> These are used only by Recon.
>
> 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.
>
> 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.
>
> What do you think?
>
> -Attila
>
> [1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html
> [2] https://db.apache.org/derby/derby_downloads.html
> [3] https://docs.spring.io/spring-framework/reference/6.0/overview.html
> [4] https://www.jooq.org/download/versions#oss
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> For additional commands, e-mail: dev-help@ozone.apache.org
>
>
Re: [DISCUSS] bump minimum required Java
Posted by Sammi Chen <sa...@apache.org>.
+1 for updating the server side java version.
But DiDi has hit one OM performance issue HDDS-11240
<https://issues.apache.org/jira/browse/HDDS-11240> when using JDK 17. Not
sure whether JDK 11 will have this issue or not.
On Sat, 16 Nov 2024 at 04:56, Attila Doroszlai <ad...@apache.org>
wrote:
> Hi Apache Ozone community,
>
> Ozone currently requires minimum Java 8 at both build and run time,
> but it compiles and runs fine with newer Java versions. The GitHub CI
> workflow includes compilation with Java 11, 17 and 21. Tests are run
> with Java 17.
>
> Java 21 has been GA for more than a year, Java 17 for 3 years now. [1]
>
> Some third-party dependencies have stopped releasing fixes for
> versions that work with Java 8.
> - Derby requires Java 21 [2]
> - Spring and jOOQ require Java 17 [3], [4]
>
> These are used only by Recon.
>
> 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.
>
> 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.
>
> What do you think?
>
> -Attila
>
> [1] https://www.oracle.com/java/technologies/java-se-support-roadmap.html
> [2] https://db.apache.org/derby/derby_downloads.html
> [3] https://docs.spring.io/spring-framework/reference/6.0/overview.html
> [4] https://www.jooq.org/download/versions#oss
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ozone.apache.org
> For additional commands, e-mail: dev-help@ozone.apache.org
>
>
Re: [DISCUSS] bump minimum required Java
Posted by Siyao Meng <si...@apache.org>.
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 <er...@apache.org> 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 <sz...@gmail.com>
> 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 <er...@cloudera.com> 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 <sz...@apache.org> 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 <er...@apache.org> 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 <sz...@apache.org>
> > > 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 <
> > > > adoroszlai@apache.org>
> > > > > > 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: dev-unsubscribe@ozone.apache.org
> > > > > > > For additional commands, e-mail: dev-help@ozone.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] bump minimum required Java
Posted by Ethan Rose <er...@apache.org>.
> 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 <sz...@gmail.com>
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 <er...@cloudera.com> 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 <sz...@apache.org> 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 <er...@apache.org> 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 <sz...@apache.org>
> > 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 <
> > > adoroszlai@apache.org>
> > > > > 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: dev-unsubscribe@ozone.apache.org
> > > > > > For additional commands, e-mail: dev-help@ozone.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] bump minimum required Java
Posted by Tsz-Wo Nicholas Sze <sz...@gmail.com>.
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 <er...@cloudera.com> 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 <sz...@apache.org> 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 <er...@apache.org> 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 <sz...@apache.org>
> 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 <
> > adoroszlai@apache.org>
> > > > 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: dev-unsubscribe@ozone.apache.org
> > > > > For additional commands, e-mail: dev-help@ozone.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: [DISCUSS] bump minimum required Java
Posted by Ethan Rose <er...@cloudera.com>.
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 <sz...@apache.org> 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 <er...@apache.org> 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 <sz...@apache.org> 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 <
> adoroszlai@apache.org>
> > > 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: dev-unsubscribe@ozone.apache.org
> > > > For additional commands, e-mail: dev-help@ozone.apache.org
> > > >
> > > >
> > >
> >
>
Re: [DISCUSS] bump minimum required Java
Posted by Tsz Wo Sze <sz...@apache.org>.
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 <er...@apache.org> 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 <sz...@apache.org> 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 <ad...@apache.org>
> > 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: dev-unsubscribe@ozone.apache.org
> > > For additional commands, e-mail: dev-help@ozone.apache.org
> > >
> > >
> >
>
Re: [DISCUSS] bump minimum required Java
Posted by Ethan Rose <er...@apache.org>.
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 <sz...@apache.org> 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 <ad...@apache.org>
> 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: dev-unsubscribe@ozone.apache.org
> > For additional commands, e-mail: dev-help@ozone.apache.org
> >
> >
>
Re: [DISCUSS] bump minimum required Java
Posted by Tsz Wo Sze <sz...@apache.org>.
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 <ad...@apache.org>
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: dev-unsubscribe@ozone.apache.org
> For additional commands, e-mail: dev-help@ozone.apache.org
>
>
Re: [DISCUSS] bump minimum required Java
Posted by Attila Doroszlai <ad...@apache.org>.
> 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: dev-unsubscribe@ozone.apache.org
For additional commands, e-mail: dev-help@ozone.apache.org