On Sat, Oct 17, 2020 at 1:45 AM Enrico Olivelli <eolive...@gmail.com> wrote:
> We must run tests using real jdk8 to test the Zookeeper client. We must

Hi Enrico,

I sort of understand your perspective, as it pertains to the
*existing* versions that are already released with Java 8 support
(3.5.x and 3.6.x), especially since the runtime testing workflow is so
tightly coupled to the build. After all, you don't want to change user
expectations in a patch release for those versions.

However, I don't understand continuing to have the same expectations
for the *next*, currently not released, version of ZooKeeper (3.7.x)
that is still under development. Now (before the ".0" release) is the
perfect time to change the requirements and set new user expectations
(to either bump it for the build only, as in my proposal, or to also
bump it for the runtime requirement). Is there a good justification
for holding back 3.7 to Java 8 and maintaining the same user
expectations and requirements for 3.7 as 3.5/3.6?

My main concerns about holding back the build requirement to JDK 8 are:
  1) extra testing burden, which will get worse when JDK 17 is
released (which will probably happen while 3.7 is still being
supported)
  2) supporting build compatibility, runtime compatibility, and all
the testing across three LTS versions of Java (8, 11, and 17), not to
mention any intermediate non-LTS Java versions, is an enormous
commitment for a small, volunteer-driven, open source project; I would
generally expect the open source project to be more narrowly focused
on fewer commitments, and letting downstream vendors/packagers pick up
those additional commitments, and
  3) Maven plugin developers aren't going to support JDK 8 forever.
Many have already begun migrating to Java 11 as their minimum, which
means those plugins won't be usable by people building their projects
with JDK 8. It won't be long before a serious bug or security
vulnerability in a build plugin affects projects' ability to build
with JDK 8. In the interests of security and stability, it would be
good to keep the build tooling up to date.

If the ZK project isn't ready to move to Java 11 for 3.7.0, not even
for the build requirement, then when will it be ready (for either the
build or runtime)? Has that already been discussed and decided by this
project's PMC in a previous thread on the mailing lists? If so, where?

Regards,
Christopher

Reply via email to