zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andor Molnar <an...@cloudera.com>
Subject Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8
Date Wed, 07 Mar 2018 11:04:55 GMT
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 <phunt@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 <andor@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 <mfenes@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 <tamaas@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 <fpj@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 <afine@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 <andor@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 <
> > fpj@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 <andor@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. tamaas@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>
> > > > ------------------------------
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message