hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@hortonworks.com>
Subject Re: Hadoop 3.x: what about shipping trunk as a 2.x release in 2015?
Date Mon, 09 Mar 2015 23:18:28 GMT

On 09/03/2015 15:56, "Andrew Wang" <andrew.wang@cloudera.com> wrote:

>I find this proposal very surprising. We've intentionally deferred
>incompatible changes to trunk, because they are incompatible and do not
>belong in a minor release. Now we are supposed to blur our eyes and
>these changes anyway? I don't see this ending well.

I'm staring at CHANGES.TXT & thinking 'how can we ship something off trunk
that has as many of these as we can get out ‹especially those shell script
bits‹ in a way that doesn't break everything. Because there's a lot of
improvements and bug fixes there which aren't going to be anyone's hands
for a long time otherwise, not just due to any proposed 3.x release
schedule, but because of the java 8 requirements as well as classloader

>One higher-level goal we should be working towards is tightening our
>compatibility guarantees, not loosening them. This is why I've been
>highlighting classpath isolation as a 3.0 feature, since this is one of
>biggest issues faced by our users and downstreams. I think a 3.0 with an
>improved compatibility story will make operators and downstreams much
>happier than releasing trunk as 2.8.

I still want to see what's being proposed here. Having classpath isolation
will make the JAR upgrade story in 3.x a lot cleaner, but we can't go to
every app that imports hadoop-hdfs-client and say "your code just broke",
not if they want their apps to continue to run on Hadoop 2 and/or Java 7.
Which, given that Java 7 is still something cluster ops teams are coming
to terms with, is going to be a while


View raw message