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

Reply via email to