hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wang <andrew.w...@cloudera.com>
Subject Re: Plans of moving towards JDK7 in trunk
Date Sat, 21 Jun 2014 15:01:53 GMT
Hi Steve, let me confirm that I understand your proposal correctly:

- Release an intermediate Hadoop 3 a few months out, based on JDK7 and with
bumped library versions
- Release a Hadoop 4 mid next year, based on JDK8

I question the utility of an intermediate Hadoop 3 like this. Assuming that
it gets out in September (i.e. roughly when a 2.6 would land), we're
looking at a valid lifespan of about 7 months before JDK7 is EOL in April.
If this release also breaks compatibility by changing library versions,
then it looks less and less appealing from a user perspective. I suspect it
would end up seeing low adoption as everyone waits (at most) 7 months for
the JDK8-based release to emerge.

I'd be more okay with an intermediate release with no incompatible changes
whatsoever besides bumping the JDK requirement to JDK7. However, it'd still
be a weak release considering that branch-2 already runs fine on JDK7, and
it looks somewhat bad publicly as we burn another major release number less
than a year since 2.x going GA.

This is why I'd like to keep my original proposal on the table: keep going
with branch-2 in the near term, while working towards a JDK8-based Hadoop 3
by April next year. It doesn't need to be a big bang release either. I'd be
delighted if we could rolling upgrade from one to the other. I just didn't
want to rule out the inclusion of some very compelling feature outright.
Trust me though, I'd be the first person to ask about compatibility if such
a feature does come up.

I'll also posit that people will shy away from using JDK8 features while
branch-2 remains in active use. There's definitely some new shiny there,
but nothing compelling enough to me personally when weighed against the
pain of harder branch-2 backports.

Let's try to keep this thread focused on the planning side of things
though, deferring JDK-feature-related discussion to a different thread.
We'd need to draw up a code-style doc on the wiki, but it sounds like
something Steve and/or I could draft initially.


On Fri, Jun 20, 2014 at 10:02 PM, Arun C Murthy <acm@hortonworks.com> wrote:

> On Jun 20, 2014, at 9:51 PM, Steve Loughran <stevel@hortonworks.com>
> wrote:
> > On 20 June 2014 21:35, Steve Loughran <stevel@hortonworks.com> wrote:
> >
> >>
> >> This actually argues in favour of
> >>
> >> -renaming branch-2 branch-3 after a release
> >> -making trunk hadoop-4
> >>
> >> -getting hadoop 3 released off the new branch-3 out in 2014, effectively
> >> being an iteration of branch-2 with updated java , moves of (off?)
> guava,
> >> off jetty, lib changes, but no other significant "big bang" features
> >>
> >>
> >> Hadoop 4.x then becomes the 2015 release, which can add more stuff. In
> >> particular, anything that goes into Hadoop 4 for which there's no
> intent to
> >> support in hadoop 2 & 3, can use the java 8 language features sooner
> rather
> >> than later.
> >>
> >>
> >>
> > I should add that I'm willing to be the person who gets the Java-7 based
> > Hadoop  3.x out the door later this year
> +1 that makes sense to me. Thanks for volunteering Steve - I'm glad to
> share the pain… ;-)
> Arun
> --
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.

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