I am surprised classpath-isolation is being called a minor issue. We have been hearing users complain about Hadoop leaking its dependencies into the classpath for a while now, Guava being the culprit often. Not being able to upgrade our dependencies without affecting users has started to hamper our development too; e.g. Guava conflict with upgrading Curator version.
If we preserve API compat and try to preserve wire compat, I don't see the harm in bumping the major release. It allows us to include several fixes/features in trunk in a release. If we are not actively thinking of a way to release items in trunk, why even have it? If there are any disadvantages to doing a major release, I would like to know. May be, we could arrive at a plan to accomplish it without those problems. Thanks Karthik On Tue, Mar 3, 2015 at 9:02 AM, Steve Loughran <ste...@hortonworks.com> wrote: > > I want to understand a lot more about the classpath isolation > (HADOOP-11656) proposal, specifically, what is proposed and does it have to > be tagged as incompatible? That's a bigger change than must setting > javac.version=8 in the POM —though given what a fundamental problem it > addresses, I'm in favour of doing something there. > > On 3 March 2015 at 08:05:46, Andrew Wang (andrew.w...@cloudera.com) wrote: > > I view branch-3 as essentially the same size as our recent 2.x releases, > with the exception of incompatible changes like classpath isolation and > JDK8 target version. These, while perhaps not revolutionary, are still > incompatible, and require a major version bump. > > -- Karthik Kambatla Software Engineer, Cloudera Inc. -------------------------------------------- http://five.sentenc.es
