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 <ste...@hortonworks.com> wrote:
>
>
> On 09/03/2015 15:56, "Andrew Wang" <andrew.w...@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
>
>
>>
>
