Steve,
________________________________________
From: Steve Loughran <ste...@hortonworks.com>
Sent: Monday, March 09, 2015 2:15 PM
To: mapreduce-...@hadoop.apache.org; hdfs-dev@hadoop.apache.org;
common-...@hadoop.apache.org; yarn-...@hadoop.apache.org
Subject: Hadoop 3.x: what about shipping trunk as a 2.x release in 2015?
Issue: Getting trunk out the door
The main diff from branch-2 and trunk is currently the bash script changes.
These don't break client apps. May or may not break bigtop & other downstream
hadoop stacks, but developers don't need to worry about this: no recompilation
necessary
Proposed: ship trunk as a 2.x release, compatible with JDK7 & Java code.
It seems to me that I could go
git checkout trunk
mvn versions:set -DnewVersion=2.8.0-SNAPSHOT
We'd then have a version of Hadoop-trunk we could ship later this year,
compatible at the JDK and API level with the existing java code & JDK7+
clusters.
A classpath fix that is optional/compatible can then go out on the 2.x line,
saving the 3.x tag for something that really breaks things, forces all
downstream apps to set up new hadoop profiles, have separate modules &
generally hate the hadoop dev team
This seems like a great idea, something I hadn't considered before since most
patches were flowing into branch-2 anyway - makes a lot of sense.
We could just drop branch-2 while we are at it too. It's just a pain to
maintain an extra branch. Also, we should formalize that major features should
always come via feature branches - allows for some oversight on compatibility
etc. as a whole (not piecemeal) when the feature branch is merged.
In particular, let's also make sure we ship the script changes in a compatible
manner. Happy to help.
Given that Vinod has stepped up for 2.7, would you like to drive 2.8?
Practically, this is reality already, but something to formalize: having RMs
per dot release (Karthik for 2.5, Vinod for 2.7, Steve for 2.8 etc.).
thanks,
Arun
