Thanks Christopher, would you please open a PR with the proposed changes for the master branch?
> On Sep 19, 2025, at 19:50, Christopher <[email protected]> wrote: > > Sounds good to me. I can help with the maven changes, too. > > On Fri, Sep 19, 2025, 11:54 Andor Molnar <[email protected]> wrote: > >> Hi all, >> >> Since our household chores have been finished with recent 3.9 and 3.8 >> version, I think we can get back to this topic. >> >> Looking at the tremendous amount of work that Kezhu is doing on master >> with client jar separations, I tend to cut 4.0.0 from master once >> everything is done. If that’d be the case we could make a leap and make JDK >> 17 the minimum runtime and compile versions for the master branch. wdyt? >> >> Once the change is merged to master, we'll backport it to branch-3.9 as >> follows: >> >> * minimum JDK for building: 17 >> * minimum JRE for running: 8 (no change) >> >> This is completely aligned with Christopher’s suggestion except we won’t >> touch the branch-3.8 as it’s going to be EoL’d in 6 months after the >> release of 4.0.0. >> >> Regards, >> Andor >> >> p.s. Due to my little Maven experience I won’t be able to make the PRs >> myself, so I’ll ask sb to volunteer. >> >> >> >> >>> On Aug 20, 2025, at 20:59, Christopher <[email protected]> wrote: >>> >>> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> 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 <[email protected]>于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 <[email protected]>于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 <[email protected]> >>>>>> 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 <[email protected]> >>>>>> 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 <[email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Does anyone know when 3.10.0 is planned to be released? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Li >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>> >>>> >> >>
