+1 to move to jdk17 both for client and server I would use 3.10 as there are no breaking changes in any protocol or sisk format. We have always been pretty good at keeping backward and forward compatibility.
Upgrading to 4.x may seem a big leap for users, and you usually are very afraid of touching foundational libraries and services like ZK. Upgrading the required jdk is not enough for such a big bump I will be happy to review the PRs Enrico Il Ven 9 Gen 2026, 06:47 Christopher <[email protected]> ha scritto: > Yes, I did offer. I'm sorry I haven't had time to work on it yet. I > think I may have time next week to help, if somebody else doesn't do > it first. > > On Thu, Jan 8, 2026 at 7:30 PM Andor Molnár <[email protected]> wrote: > > > > Personally I’m waiting for somebody who has experience with Maven to put > together a patch against the master branch with the proposed JDK/JRE > changes. > > > > As far as I remember Christopher has offered help. > > > > Regards, > > > > Andor > > > > > > > > > > > On Jan 8, 2026, at 15:59, Li Wang <[email protected]> wrote: > > > > > > Happy New Year! > > > > > > Just wonder if there is any update on the target date/timeframe for > the new > > > 4.0.0/3.10 release? > > > > > > Thanks, > > > > > > Li > > > > > > > > > On Tue, Sep 23, 2025 at 12:31 AM Andor Molnar <[email protected]> > wrote: > > > > > >> 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 > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>>> > > >>>>>>>>>>>>>>> > > >>>>>>>>>>>>>> > > >>>>>>>>>>>>> > > >>>>>>>>>>>> > > >>>>>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>> > > >>>> > > >> > > >> > > >
