Originally I proposed 4.0.0 for the new release, but I think I prefer 3.10.0 now. 4.0.0 suggests a bigger change: incompatible API changes, major protocol upgrade like gRPC, some big new feature, architectural change, etc. Something which we’re not planning to ship, but anyone feel free to correct me if something really impactful is waiting on master branch to be released. I’m not aware of anything like that.
So, from that perspective 4.0.0 would be disappointing to our users. On the other hand, the pace that Java develops nowadays suggests that moving forward with minimum runtime version requirement should be the natural way of projects to develop. It’s something that everybody should be prepared for from operational perspective. Minor version number increase should be enough to indicate such change. This reminds me a bit for the first time I was facing with Let’s Encrypt. Come’on who the heck wants to renew HTTPS certificates every 90 days? That’s crazy. Today that’s just business as usual operation for websites and nevertheless, it’s fully automated. Should we upgrade two Java versions at once? No, we should not to. But unfortunately ZooKeeper lags behind too much, so we need to make a bigger step now to catch up and in the future we should follow the pace of Java LTS releases in ZooKeeper releases. Andor ps. I really want to make the Jetty upgrade ;) > On Aug 20, 2025, at 21:01, Christopher <ctubb...@apache.org> wrote: > > I understand. Jetty has been pretty aggressive at updating to jakarta and > newer Java versions. It's hard to keep Jetty up-to-date. What do you think > about just calling it 4.0 and skipping 3.10? > > On Tue, Aug 19, 2025 at 9:14 PM Andor Molnar <an...@apache.org> wrote: > >> We cannot upgrade Jetty if we stay on JDK11, which is my biggest concern >> about it. >> >> >> >> >>> On Aug 19, 2025, at 19:11, Christopher <ctubb...@apache.org> wrote: >>> >>> Sorry for the confusion. I linked that PR mostly for my own reference >>> to review to make a new PR. You can ignore that PR for now. I would >>> create a new one for this. I was getting ahead of myself, because I >>> know that bumping the minimum build version would also include a bump >>> of the Apache parent POM, which also means some other related POM >>> cleanup. That linked Draft PR is not related to this, except it >>> contains some general POM cleanup that would be good to include when >>> bumping the Apache parent POM. >>> >>> I was thinking: >>> >>> * release 3.8.5 (that will not benefit from these changes, and needs >>> to be EOL ASAP) >>> * optionally release 3.9.4 (this action is not a blocker for 3.9) >>> * create a PR that bumps the Apache parent POM, establishes the >>> minimalJavaBuildVersion as 11 (or 17), and performs related POM >>> cleanup (keep Java 8 as the target version) >>> * apply that PR to 3.9 and master >>> * create a PR that bumps the target version for Java to 11, and apply >>> to master only >>> * release 3.10 >>> >>> I would not bump the target Java version for runtime to 17 for the >>> 3.10 branch. I would wait for 4.0 for that. I would keep it at 11. The >>> build version can be 11 or 17. >>> >>> On Tue, Aug 19, 2025 at 6:18 PM Andor Molnar <an...@apache.org> wrote: >>>> >>>> Okay. I checked the pull request that you linked and there’s a lot more >> in that most of which I don’t even understand. I suggest the following: >>>> >>>> - let’s finish that PR by adding minimum build version of JDK 11 for >> now, >>>> - merge the PR to all active branches: master, branch-3.9 and >> branch-3.8, >>>> - release 3.9.4 and 3.8.5, >>>> - create another patch which bumps the minimum build _and_ runtime >> version to JDK 17 on the master branch only, >>>> - release 3.10.0. >>>> >>>> wdyt? >>>> >>>> I’d like to keep the minimum required build version to JDK 11 on the >> stable branches 3.8 and 3.9. Does it make any sense? >>>> >>>> Andor >>>> >>>> >>>> >>>> >>>>> On Aug 19, 2025, at 13:12, Christopher <ctubb...@apache.org> wrote: >>>>> >>>>> Thanks for bringing my suggestion to the mailing list for discussion. >>>>> >>>>> I wasn't aware that 17 was being considered. Is there another >>>>> discussion thread I can read about that? >>>>> >>>>> My suggestion could apply with JDK 17 instead of 11. I didn't suggest >>>>> 17 because I thought 11 would be more acceptable as a smaller >>>>> incremental jump. However, if there is already a goal to move to 17, >>>>> then applying my suggestion with JDK 17 as the minimum would be a good >>>>> first step. Making the minimum build version 11 or 17 could be done on >>>>> all active branches. Changing the target runtime version to 11 or 17 >>>>> should only happen in the main branch, and can be done later, when the >>>>> project is ready for that. Bumping the minimal build version is >>>>> independent of bumping the target version for runtime. >>>>> >>>>> The Maven enforcer setting task is run automatically with newer Apache >>>>> parent POMs (see >>>>> https://repo1.maven.org/maven2/org/apache/apache/35/apache-35.pom). ZK >>>>> uses an older version and it needs to be updated anyway. >>>>> >>>>> If bumping the build version to 11 or 17 is agreed, I volunteer to >>>>> create a PR for it. I would probably also revisit my earlier PR to >>>>> remove maven-antrun-plugin >>>>> (https://github.com/apache/zookeeper/pull/2241) because there are some >>>>> general POM cleanup stuff in that PR that would probably be good to >>>>> borrow from that PR to include in a POM update. >>>>> >>>>> On Mon, Aug 18, 2025 at 10:37 AM Andor Molnar <an...@apache.org> >> wrote: >>>>>> >>>>>> Hi team, >>>>>> >>>>>> Christopher has a suggestion on the Owasp upgrade PR which I think we >> should discuss here. >>>>>> >>>>>> TL;DR - Since Owaps requires Java 11 after upgrade, let's bump the >> minimum required Java version for _BUILDING_ ZooKeeper to 11 across all >> build profiles. >>>>>> >>>>>> That additional change will allow lots of plugins to be updated that >> require newer Java versions, but the maven.compiler.release property set to >> 8 in the ZK pom.xml would still keep ZK compatible with Java 8 at runtime. >>>>>> >>>>>> … >>>>>> >>>>>> I think it's an inconvenience to have two separate minimum versions, >> depending on which tasks one executes. Also, there are other reasons to >> standardize on the minimum being JDK11 for everything: >>>>>> >>>>>> • in this case, only OWASP requires a different minimum JDK... but >> next time, a plugin that is part of the main build might require JDK11. >> Making JDK11 the minimum for everything would help avoid such problems in >> the future, >>>>>> • older JDK versions are increasingly harder to acquire in newer >> operating systems and corporate environments where security policies >> prevent the use of older software, so fewer people over time are actually >> building and testing with JDK8; so, continuing to support it is >> increasingly a waste of effort, >>>>>> • JDK11 has stricter Java 8 compliance enforcement than JDK 8 does, >> so it's better to build with JDK11 if you want to support JRE8. >>>>>> >>>>>> See the full conversation here: >>>>>> https://github.com/apache/zookeeper/pull/2297 >>>>>> >>>>>> I think this is acceptable, but not sure if it’s worth the effort >> since we’re going to upgrade to JDK 17 project-wise anyways. >>>>>> >>>>>> Consider that with this change we have to do the following: >>>>>> - modify maven enforcer settings in parent POM, >>>>>> - add documentation changes explaining the situation, >>>>>> - remove JDK8 github actions, >>>>>> - change Apache CI Jenkinsfile and remove JDK 8 builds completely. >>>>>> >>>>>> It’s also true that JDK 17 upgrade is not going to happen tomorrow. >>>>>> >>>>>> Please share your thoughts. >>>>>> >>>>>> Regards, >>>>>> Andor >>>>>> >>>>>> p.s. I don’t find the maven enforcer setting myself which needs to be >> bumped in parent pom, but if someone can point me to it or even create a PR >> with the above mentioned changes, I’d much appreciate that. >>>>>> >>>>>> >>>> >> >>
