Mailing-List: contact hdfs-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hdfs-dev@hadoop.apache.org
Received-SPF: pass (nike.apache.org: domain of tucu00@gmail.com designates
 74.125.82.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CFB90E86-24D5-4E49-90D1-B6B873E77B70@hortonworks.com>
References: 
 <CAGB5D2Za9UHLjw1_+xNcJ0nSyWkJT2fXogCq_SUi6baFEv6+gQ@mail.gmail.com>
 <1425349807827.88706@hortonworks.com>
 <CAGB5D2a=5_46UcyKc+EoG08gYo=R-VDj+rnr7q9pjxj2kjuVNA@mail.gmail.com>
 <C48CA17E-D191-44BF-80E5-1F472CBF712E@hortonworks.com>
 <1425421960667.60647@hortonworks.com>
 <CAGB5D2Z+tWoagDO3i6Y5kEUPygHEip2MyRrLLB0Yh7vh+MCKGA@mail.gmail.com>
 <CFB90E86-24D5-4E49-90D1-B6B873E77B70@hortonworks.com>
From: Alejandro Abdelnur <tucu00@gmail.com>
Date: Thu, 5 Mar 2015 13:05:56 -0800
Message-ID: 
 <CACDdcgdyPXqmn3W5tOGiv0fp2xkUz=5WoJzwXKZsZkeGP9UWSg@mail.gmail.com>
Subject: Re: Looking to a Hadoop 3 release
To: yarn-dev@hadoop.apache.org,
	"hdfs-dev@hadoop.apache.org" <hdfs-dev@hadoop.apache.org>,
	"common-dev@hadoop.apache.org" <common-dev@hadoop.apache.org>,
	"mapreduce-dev@hadoop.apache.org" <mapreduce-dev@hadoop.apache.org>
Content-Type: multipart/alternative; boundary=f46d04138cdf4f57ca051090f06e

--f46d04138cdf4f57ca051090f06e
Content-Type: text/plain; charset=UTF-8

IMO, if part of the community wants to take on the responsibility and work
that takes to do a new major release, we should not discourage them from
doing that.

Having multiple major branches active is a standard practice.

This time around we are not replacing the guts as we did from Hadoop 1 to
Hadoop 2, but superficial surgery to address issues were not considered (or
was too much to take on top of the guts transplant).

For the split brain concern, we did a great of job maintaining Hadoop 1 and
Hadoop 2 until Hadoop 1 faded away.

Based on that experience I would say that the coexistence of Hadoop 2 and
Hadoop 3 will be much less demanding/traumatic.

Also, to facilitate the coexistence we should limit Java language features
to Java 7 (even if the runtime is Java 8), once Java 7 is not used anymore
we can remove this limitation.

Thanks.


On Thu, Mar 5, 2015 at 11:40 AM, Vinod Kumar Vavilapalli <
vinodkv@hortonworks.com> wrote:

> The 'resistance' is not so much about  a new major release, more so about
> the content and the roadmap of the release. Other than the two specific
> features raised (the need for breaking compat for them is something that I
> am debating), I haven't seen a roadmap of branch-3 about any more features
> that this community needs to discuss about. If all the difference between
> branch-2 and branch-3 is going to be JDK + a couple of incompat changes, it
> is a big problem in two dimensions (1) it's a burden keeping the branches
> in sync and avoiding the split-brain we experienced with 1.x, 2.x or worse
> branch-0.23, branch-2 and (2) very hard to ask people to not break more
> things in branch-3.
>
> We seem to have agreed upon a course of action for JDK7. And now we are
> taking a different direction for JDK8. Going by this new proposal, come
> 2016, we will have to deal with JDK9 and 3 mainline incompatible hadoop
> releases.
>
> Regarding, individual improvements like classpath isolation, shell script
> stuff, Jason Lowe captured it perfectly on HADOOP-11656 - it should be
> possible for every major feature that we develop to be a opt in, unless the
> change is so great and users can balance out the incompatibilities for the
> new stuff they are getting. Even with an ground breaking change like with
> YARN, we spent a bit of time to ensure compatibility (MAPREDUCE-5108) that
> has paid so many times over in return. Breaking compatibility shouldn't
> come across as too cheap a thing.
>
> Thanks,
> +Vinod
>
> On Mar 4, 2015, at 10:15 AM, Andrew Wang <andrew.wang@cloudera.com<mailto:
> andrew.wang@cloudera.com>> wrote:
>
> Where does this resistance to a new major release stem from? As I've
> described from the beginning, this will look basically like a 2.x release,
> except for the inclusion of classpath isolation by default and target
> version JDK8. I've expressed my desire to maintain API and wire
> compatibility, and we can audit the set of incompatible changes in trunk to
> ensure this. My proposal for doing alpha and beta releases leading up to GA
> also gives downstreams a nice amount of time for testing and validation.
>
>

--f46d04138cdf4f57ca051090f06e--