Hi All, Just to add my 2 cents. // Might be five, I write long. :) Hope, you find valuable bits.
As many of us I also hope that ZooKeeper 3.5 will be released soon. Until then most of the changes go into master and branch-3.5 too, so I would keep them on the same Java version for code compatibility. In the same time I'd be happy if it was Java 8. ZK 3.5+ supports Java 7 since December 2014, an almost 7 year old Java version today. It was a perfect decision in 2014, when nobody expected ZK 3.5 coming so late, but things might be different four years later. Since we have to keep compatibility with Java 6 on branch-3.4 we already need manual changes when cherry picking into that branch. Not much difference if branch-3.5 is Java 8. As Flavio said changing branch-3.5 to Java 8 might cause issues for users already using ZK 3.5.x-beta. I totally agree with that concern, but using a beta state software means you accept the risk of facing changes. And Java 8 is four years old now, so we would not change to bleeding edge, which I guess nobody wanted. So what I would propose is the following: - Upgrade branches "master" and "branch-3.5" to Java 8 (LTS) asap. - After releasing 3.5 GA and the next LTS Java version (Java 11 / 18.9-LTS) gets released upgrade "master" branch to Java 11-LTS. ( http://www.oracle.com/technetwork/java/eol-135779.html) - I would not upgrade Java to a non-LTS version. What do you think about it? Thanks, Tamaas On Mon, Feb 19, 2018 at 10:32 PM, Flavio Junqueira <f...@apache.org> wrote: > I'm fine with moving to Java 8 or even 9 in 3.6. Does anyone have a > different option? Otherwise, should we start a vote? > > -Flavio > > > > On 16 Feb 2018, at 21:28, Abraham Fine <af...@apache.org> wrote: > > > > I'm a -1 on requiring different minimum versions of java for the client > and the server. I think this has the potential to create a lot of > confusion for users and contributors. > > > > I would support moving master (3.6) to java 8, I also think it is worth > considering moving to java 9. Given how long our release cycle tends to be > I think targeting the latest and greatest this early in the development > cycle is reasonable. > > > > Thanks, > > Abe > > > > On Fri, Feb 16, 2018, at 06:48, Enrico Olivelli wrote: > >> 2018-02-16 14:20 GMT+01:00 Andor Molnar <an...@cloudera.com>: > >> > >>> +1 for setting the Java8 requirement on server side. > >>> > >>> *Client side.* > >>> I'd like the idea of the setting the requirement on client side too > without > >>> introducing anything Java8 specific. I'm not planning to use Java8 > features > >>> right on, just thinking of opening the gates would be useful in the > long > >>> run. > >>> > >>> Additionally, I don't see heavy development on the client side. Users > who > >>> are tightly coupled to Java7 are still able to use existing clients as > long > >>> as we introduce something breaking which they're forced to upgrade to > for > >>> whatever reason. I'm not sure what are the odds of that to happen. > >>> > >> > >> > >> My two cents > >> Actually ZooKeeper is distributed as a single JAR which contains both > >> server and client side code, requiring Java 7 for the client and Java 8 > for > >> the server will require a new way of packaging the artifacts and > building > >> the project (and this will require separating client side and server > side > >> code base). > >> Maybe I am missing something. > >> > >> > >> Enrico > >> > >> > >>> > >>> Andor > >>> > >>> > >>> > >>> On Fri, Feb 16, 2018 at 12:31 PM, Flavio Junqueira <f...@apache.org> > wrote: > >>> > >>>> We have this section in the admin doc that talks about the system > >>>> requirements: > >>>> > >>>> https://zookeeper.apache.org/doc/r3.5.3-beta/zookeeperAdmin.html#sc_ > >>>> requiredSoftware <https://zookeeper.apache.org/doc/r3.5.3-beta/ > >>>> zookeeperAdmin.html#sc_requiredSoftware> > >>>> > >>>> If we change, then we have to update that section. Specifically about > >>>> client and server, I'd think that there is no problem with requiring > >>> Java 8 > >>>> on the server. The potential concern is with the client as it affects > >>>> applications that build against it. It would be best to not force > >>>> applications to upgrade themselves. Looking at the compatibility guide > >>> for > >>>> Java 8: > >>>> > >>>> http://www.oracle.com/technetwork/java/javase/8- > >>>> compatibility-guide-2156366.html <http://www.oracle.com/ > >>>> technetwork/java/javase/8-compatibility-guide-2156366.html> > >>>> > >>>> The risk is that an application is strictly using Java 7 because of > some > >>>> incompatibility listed in that guide, in which case, it wouldn't be > able > >>> to > >>>> compile the ZK client assuming we get it to use some Java 8 construct. > >>> One > >>>> option is that we raise the requirement to Java 8, but we do no really > >>>> introduce anything that breaks compatibility for the next version. > Users > >>>> should take this as a warning that they need to migrate to Java 8. I'm > >>> not > >>>> sure this makes the situation any better, though. Another option is > that > >>> we > >>>> set a release to be the one in which we migrate and let everyone know > >>> that > >>>> they need to migrate. > >>>> > >>>> -Flavio > >>>> > >>>> > >>>>> On 16 Feb 2018, at 12:05, Andor Molnar <an...@cloudera.com> wrote: > >>>>> > >>>>> Hi all, > >>>>> > >>>>> I think it would be nice to draw a line at branch-3.5 and target Java > >>>>> version 8 onwards. It seems to be a good opportunity for the upgrade > >>>> before > >>>>> we release a stable version of 3.5. > >>>>> > >>>>> The benefit would be the ability to use new features of Java 8 in the > >>>> code: > >>>>> > >>>>> Do think it's feasible? > >>>>> > >>>>> Regards, > >>>>> Andor > >>>> > >>>> > >>> > > -- *Tamás **Pénzes* | Engineering Manager e. tam...@cloudera.com cloudera.com <http://www.cloudera.com/> [image: Cloudera] <http://www.cloudera.com/> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera> ------------------------------
