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