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 >
