hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Wittenauer ...@altiscale.com>
Subject Re: Hadoop 3.x: what about shipping trunk as a 2.x release in 2015?
Date Tue, 10 Mar 2015 01:13:25 GMT

	Between this and the other thread, I’m seeing:

	* companies that were forced to make internal forks because their patches were ignored are
now considered the deciders for whether we move forward
	* 5 years since the last branch off of trunk is considered ‘soon’
	* More good reasons to kill hadoop 2.7 and release hadoop 3.0 as the JDK7 release
	* We are now OPENLY hostile to operations teams
	* No one seems to really care that we’re about to create an absolute nightmare for anyone
that uses maven repos, as they’ll need to keep track of which jars have been compiled with
which JVM with zero hints from our build artifacts

On Mar 9, 2015, at 4:18 PM, Steve Loughran <stevel@hortonworks.com> wrote:

> 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
>> release
>> 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
> stuff.
>> 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
>> the
>> 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.
>> Best,
>> Andrew
> 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