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 > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>> > >>>> > >>> > >> > >
