hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chen He <airb...@gmail.com>
Subject Re: Looking to a Hadoop 3 release
Date Tue, 03 Mar 2015 01:01:34 GMT
+1 non-binding

It is a nice to have hadoop 3.x release. My honor to help.

Regards!

Chen

On Mon, Mar 2, 2015 at 4:58 PM, Zheng, Kai <kai.zheng@intel.com> wrote:

> Sorry for the bad. I thought it was sending to my colleagues.
>
> By the way, for the JDK8 support, we (Intel) would like to investigate
> further and help, thanks.
>
> Regards,
> Kai
>
> -----Original Message-----
> From: Zheng, Kai
> Sent: Tuesday, March 03, 2015 8:49 AM
> To: common-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
> hdfs-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org
> Subject: RE: Looking to a Hadoop 3 release
>
> JDK8 support is in the consideration, looks like many issues were reported
> and resolved already.
>
> https://issues.apache.org/jira/browse/HADOOP-11090
>
>
> -----Original Message-----
> From: Andrew Wang [mailto:andrew.wang@cloudera.com]
> Sent: Tuesday, March 03, 2015 7:20 AM
> To: common-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org;
> hdfs-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org
> Subject: Looking to a Hadoop 3 release
>
> Hi devs,
>
> It's been a year and a half since 2.x went GA, and I think we're about due
> for a 3.x release.
> Notably, there are two incompatible changes I'd like to call out, that
> will have a tremendous positive impact for our users.
>
> First, classpath isolation being done at HADOOP-11656, which has been a
> long-standing request from many downstreams and Hadoop users.
>
> Second, bumping the source and target JDK version to JDK8 (related to
> HADOOP-11090), which is important since JDK7 is EOL in April 2015 (two
> months from now). In the past, we've had issues with our dependencies
> discontinuing support for old JDKs, so this will future-proof us.
>
> Between the two, we'll also have quite an opportunity to clean up and
> upgrade our dependencies, another common user and developer request.
>
> I'd like to propose that we start rolling a series of monthly-ish series of
> 3.0 alpha releases ASAP, with myself volunteering to take on the RM and
> other cat herding responsibilities. There are already quite a few changes
> slated for 3.0 besides the above (for instance the shell script rewrite) so
> there's already value in a 3.0 alpha, and the more time we give downstreams
> to integrate, the better.
>
> This opens up discussion about inclusion of other changes, but I'm hoping
> to freeze incompatible changes after maybe two alphas, do a beta (with no
> further incompat changes allowed), and then finally a 3.x GA. For those
> keeping track, that means a 3.x GA in about four months.
>
> I would also like to stress though that this is not intended to be a big
> bang release. For instance, it would be great if we could maintain wire
> compatibility between 2.x and 3.x, so rolling upgrades work. Keeping
> branch-2 and branch-3 similar also makes backports easier, since we're
> likely maintaining 2.x for a while yet.
>
> Please let me know any comments / concerns related to the above. If people
> are friendly to the idea, I'd like to cut a branch-3 and start working on
> the first alpha.
>
> Best,
> Andrew
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message