>From the responses on 'user' list, I think we are good to go. What do you think?
Andor On Wed, Mar 7, 2018 at 12:04 PM, Andor Molnar <an...@cloudera.com> wrote: > Okay, I dropped a mail on the user list to get some feedback. > > > Regards, > Andor > > > On Thu, Feb 22, 2018 at 5:59 PM, Patrick Hunt <ph...@apache.org> wrote: > >> Perhaps discuss on the user list as Flavio mentioned prior to calling a >> vote? Has anyone looked at dependencies, is this consistent with what the >> rest of the ecosystem has defined. Hadoop/Hbase/Kafka/... components, >> Curator, etc... >> >> Regards, >> >> Patrick >> >> On Thu, Feb 22, 2018 at 7:52 AM, Andor Molnar <an...@cloudera.com> wrote: >> >> > Is everybody happy with the plan that Tamaas suggested? >> > Shall we start a vote? >> > >> > Andor >> > >> > >> > >> > On Wed, Feb 21, 2018 at 11:34 PM, Mark Fenes <mfe...@cloudera.com> >> wrote: >> > >> > > Hi All, >> > > >> > > I totally support the idea of upgrading to Java 8 and I agree with Abe >> > that >> > > we should not require different minimum versions of Java for the >> client >> > and >> > > the server. >> > > Also skipping the non-LTS versions sounds reasonable. >> > > >> > > Regards, >> > > Mark >> > > >> > > >> > > On Tue, Feb 20, 2018 at 8:49 PM, Tamás Pénzes <tam...@cloudera.com> >> > wrote: >> > > >> > > > 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> >> > > > ------------------------------ >> > > > >> > > >> > >> > >
