I'd recommend starting a separate [VOTE] thread to make it more obvious. Is there a jira? I didn't see it on this thread, would be good to create/document.
Regards, Patrick On Thu, Mar 22, 2018 at 10:43 AM, Andor Molnar <an...@cloudera.com> wrote: > Silence probably means 'yes', so I start the vote now. > > *Shall we upgrade the minimum required Java version to compile and run > ZooKeeper on 3.5 and master branches to Java 1.8?* > > *Yes / No* > > I vote for 'Yes'. > > Regards, > Andor > > > > On Mon, Mar 19, 2018 at 1:35 PM, Andor Molnar <an...@cloudera.com> wrote: > > > 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> > >>> > > > ------------------------------ > >>> > > > > >>> > > > >>> > > >>> > >> > >> > > >
