zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Hunt <ph...@apache.org>
Subject Re: [SUGGESTION] Target branches 3.5 and master (3.6) to Java 8
Date Thu, 22 Mar 2018 17:47:33 GMT
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 <andor@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 <andor@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 <andor@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 <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