+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.zh...@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-...@hadoop.apache.org; > hdfs-...@hadoop.apache.org; yarn-...@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.w...@cloudera.com] > Sent: Tuesday, March 03, 2015 7:20 AM > To: common-dev@hadoop.apache.org; mapreduce-...@hadoop.apache.org; > hdfs-...@hadoop.apache.org; yarn-...@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 >
