It looks like that Confluence page is pretty close to Semver 2.0's definition (semver.org). I was confused by the use of the word "major" to refer to 3.10 earlier in this thread. By the definition there, it'd be a "minor" release.
Since the version numbering is based on API changes, and not dependency requirements, it is permissible to update dependencies substantially, without breaking any documented goal. However, I still think going to 17 in a 3.x minor release is a bit too much for existing 3.x users who are trying to stay up-to-date on 3.x. I think 11 is less disruptive for a minor version bump. But, I also think it would be okay to release 4.0 from the master branch instead of 3.10, and make bigger, more disruptive changes. My main concern is whether users on 3.x will be properly prepared for the risks of disruptive changes. If the version is called 3.10, they may think it to be low-risk, but if it is called 4.0, they will recognize it as riskier and can prepare for it. Users tend to infer a lot about the risk level from the name of the version, and a major version number change communicates bigger risk that users may need to prepare for. In any case, I certainly don't feel too strongly about it. Although my preference would be to have 11 as the runtime minimum for 3.10, I would prefer 17 rather than staying on 8. My preferences are: * minimum JDK for building all active branches (3.9 and later): 17 * minimum JRE for running 3.9: 8 (no change) * minimum JRE for running 3.10: 11 > 17 > 8 * minimum JRE for running a future 4.x: 17 On Wed, Aug 20, 2025 at 6:38 PM Patrick Hunt <ph...@apache.org> wrote: > FYI here's what documented for the project: > > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=24193438#Roadmap-ReleaseNumbering > I personally think about it along these lines: "Upgrading between major > releases will generally require changes to user code". > The "annually" - I guess that was aspirational. :-) > > Regards, > > Patrick > > On Tue, Aug 19, 2025 at 5:24 PM Christopher <ctubb...@apache.org> wrote: > > > I think most people interpret Java/maven version numbers (x.y.z) as: > > x = major > > y = minor > > z = patch/bugfix > > > > I think it's confusing when you say 3.10 is a "major" version. What would > > you call 4.0.0? A "supremely major" release, perhaps? It's fine to treat > a > > minor release as a substantial change, but for communication, I think > it's > > still a minor release unless you bump the "major" portion of the version. > > > > I like the changes that you're planning, but I think they might be > > significant enough to call it a "major" version and bump to 4.0.0. There > > doesn't need to be a 3.10... you can just rename it anytime before it is > > released. > > > > > > On Tue, Aug 19, 2025 at 2:46 PM Andor Molnar <an...@apache.org> wrote: > > > > > We agreed on that we cut 3.10.0 from the master branch as new major > > > release of ZooKeeper. There’s no plan for 4.0.0 right now. > > > > > > Bumping minimum JDK version to JDK 17 is for 3.10.0 only. > > > > > > I suggested JDK 17, because I’d like to do a major refactoring to > upgrade > > > Jetty to the latest (12.1) version and it requires Java 17 in the > > runtime. > > > I know it sounds like a big jump, but consider that Java 11 is already > > > outdated. (EoS was Sept 2023) > > > > > > Every version of Jetty including and earlier than 11 is already EoL, so > > we > > > don’t benefit too much from a JDK 11 upgrade. > > > > > > ZooKeeper 3.9.x will be supported and stay the stable version of Apache > > > ZooKeeper for a long long time, so people running on Java 8 and 11 are > > > still covered. > > > > > > Best, > > > Andor > > > > > > > > > > > > > > > > > > > On Aug 19, 2025, at 13:18, Christopher <ctubb...@apache.org> wrote: > > > > > > > > I have reservations about bumping the minimum runtime Java version to > > > > 17, because I have applications that use ZooKeeper client code that > > > > run Java 11. I think a more modest change would be to bump the > > > > required build version to 17, but keep the target version at 11. If > > > > this is being considered for 4.0.0 only, then I'm okay with just > going > > > > to 17 for the runtime version as well. I think my existing > > > > applications that run on java 11 can continue to use 3.x. > > > > > > > > On Mon, Aug 18, 2025 at 8:44 AM Kezhu Wang <kez...@apache.org> > wrote: > > > >> > > > >> Hi all, > > > >> > > > >> +1 to upgrade to JDK 17 > > > >> > > > >> Ideally, I would suggest using different jdk versions for client and > > > >> server to not push client usage just like kafka[1] and pulsar[2]. > But > > > >> given the fact that we don't have a slim client jar[3], so +1 to > this. > > > >> > > > >> +1 to call next release from master as 3.10.0 > > > >> > > > >> I think most of the code changes in master since 3.9 were expected > to > > > >> be shipped in 3.10.0. One can confirm this in zookeeperAdmin.md. I > > > >> don't think it is worth bumping to 4.x near its release. > > > >> > > > >> I expect 4.x to be a planned version to do some ambitious tasks and > > > >> probably in a not backward compatible way such as ZOOKEEPER-233[3], > > > >> ZOOKEEPER-835[4] or ZOOKEEPER-22[5]. Also, there is 4.0.0 in > jira[6]. > > > >> > > > >> I do think bumping to JDK 17 could also be considered as a breaking > > > >> change, but that could be trivial for dependants to solve and not > > > >> touching zookeeper related codes. I would prefer new > features(probably > > > >> along with breaking changes) from our side in major releases. > > > >> > > > >> [1]: https://kafka.apache.org/40/documentation/compatibility.html > > > >> [2]: > > > > > > https://github.com/apache/pulsar?tab=readme-ov-file#pulsar-runtime-java-version-recommendation > > > >> [3]: https://issues.apache.org/jira/browse/ZOOKEEPER-233 > > > >> [4]: https://issues.apache.org/jira/browse/ZOOKEEPER-835 > > > >> [5]: https://issues.apache.org/jira/browse/ZOOKEEPER-22 > > > >> [6]: > > > https://issues.apache.org/jira/projects/ZOOKEEPER/versions/12313382 > > > >> > > > >> > > > >> On Sun, Aug 10, 2025 at 9:34 AM Andor Molnar <an...@apache.org> > > wrote: > > > >>> > > > >>> What tech debt do you mean exactly? > > > >>> > > > >>> I'm happy either way, don't have strong opinion, we can stay at > 3.x.x > > > >>> versioning. > > > >>> > > > >>> Andor > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> On 8/9/25 06:40, tison wrote: > > > >>>> Or instead, from a different perspective, if we call a 4.0, can we > > > pay back > > > >>>> some tech debt just for compatibility? > > > >>>> > > > >>>> Best, > > > >>>> tison. > > > >>>> > > > >>>> > > > >>>> tison <wander4...@gmail.com>于2025年8月9日 周六18:30写道： > > > >>>> > > > >>>>> +1 for JDK17 > > > >>>>> > > > >>>>> -0 for 4.0. Bumping JDK version doesn't break APIs and contracts. > > So > > > I'd > > > >>>>> prefer 3.10. 4.0 may give a signal of a big break change but it > > > isn't. > > > >>>>> > > > >>>>> Best, > > > >>>>> tison. > > > >>>>> > > > >>>>> > > > >>>>> Li Wang <li4w...@gmail.com>于2025年8月9日 周六08:51写道： > > > >>>>> > > > >>>>>> That's awesome. Thanks for driving this, Andor! > > > >>>>>> > > > >>>>>> After releasing 3.9.4 I’d like to announce EoL of the 3.8.x > > release > > > line > > > >>>>>>> and create a new minor/major off the master branch. > > > >>>>>> > > > >>>>>> > > > >>>>>> Does this mean the next major version (i.e. 4.0.0/3.10.0) will > be > > > released > > > >>>>>> soon, as we need to have a new current release before announcing > > > EoL of > > > >>>>>> the > > > >>>>>> 3.8.x release? > > > >>>>>> > > > >>>>>> Given the 3.9.4 release is in progress, any rough idea on when > the > > > next > > > >>>>>> major version will be? > > > >>>>>> > > > >>>>>> what if we rather call the new release 4.0.0 > > > >>>>>> > > > >>>>>> +1 for calling it 4.0.0. Looks like we have been on 3.x for > about > > > 17 years > > > >>>>>> already. > > > >>>>>> > > > >>>>>> what if we make two steps forward instead of one and let Java 17 > > to > > > be the > > > >>>>>>> minimum requirement > > > >>>>>> > > > >>>>>> +1 for Java 17 > > > >>>>>> > > > >>>>>> Best, > > > >>>>>> > > > >>>>>> Li > > > >>>>>> > > > >>>>>> > > > >>>>>> On Fri, Aug 8, 2025 at 2:38 PM Patrick Hunt <ph...@apache.org> > > > wrote: > > > >>>>>> > > > >>>>>>> Thanks for driving this Andor! I think what you are saying > makes > > > sense, > > > >>>>>>> will be interested to see what other ppl think. > > > >>>>>>> > > > >>>>>>> Regards, > > > >>>>>>> > > > >>>>>>> Patrick > > > >>>>>>> > > > >>>>>>> On Fri, Aug 8, 2025 at 2:27 PM Andor Molnar <an...@apache.org> > > > wrote: > > > >>>>>>> > > > >>>>>>>> Hi Li, > > > >>>>>>>> > > > >>>>>>>> The topic comes up every so often on the Dev list, so let’s > > bring > > > it > > > >>>>>> up > > > >>>>>>>> again. After releasing 3.9.4 I’d like to announce EoL of the > > 3.8.x > > > >>>>>>> release > > > >>>>>>>> line and create a new minor/major off the master branch. I’d > > like > > > to > > > >>>>>> drop > > > >>>>>>>> Java 8 support in that release and make Java 11 as minimum > > > requirement > > > >>>>>>> for > > > >>>>>>>> ZooKeeper. > > > >>>>>>>> > > > >>>>>>>> * In which case, what if we rather call the new release 4.0.0? > > > >>>>>>>> * Additionally what if we make two steps forward instead of > one > > > and > > > >>>>>> let > > > >>>>>>>> Java 17 to be the minimum requirement? With that, we could > > upgrade > > > >>>>>> Jetty > > > >>>>>>> to > > > >>>>>>>> the latest actively supported version. > > > >>>>>>>> > > > >>>>>>>> Please share your thoughts. > > > >>>>>>>> > > > >>>>>>>> Andor > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>>>> On May 7, 2025, at 13:16, Li Wang <li4w...@gmail.com> wrote: > > > >>>>>>>>> > > > >>>>>>>>> Hello, > > > >>>>>>>>> > > > >>>>>>>>> Does anyone know when 3.10.0 is planned to be released? > > > >>>>>>>>> > > > >>>>>>>>> Thanks > > > >>>>>>>>> > > > >>>>>>>>> Li > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>> > > > >>> > > > > > > > > >
