After further consideration, here is an alternate. On Jun 21, 2014, at 11:14 AM, "Arun C. Murthy" <a...@hortonworks.com> wrote: > > JDK6 eol was Feb 2013 and, a year later, we are still have customers using it > - which means we can't drop it yet. > > http://www.oracle.com/technetwork/java/eol-135779.html > > Given that, it seems highly unlikely everyone will suddenly jump to JDK8 by > April of next year... I suspect this means we'd have to support JDK7 at least > till late 2015. I think, that, is really key regardless of version numbers. > > Furthermore, if we, as a community, maintain discipline in terms of > wire-compat, rolling-upgrades etc. we are better off making a major release > every year - as you put, no more 'Big Bang' releases.
Looking at the big picture, I believe the users of Apache Hadoop would be better served by us if we prioritized operational aspects such as rolling upgrades, wire-compatibility, binary etc. for a couple of years. Since not everyone has moved to hadoop-2 yet, talk of more incompatibility between hadoop-2/hadoop-3 or between hadoop-3/hadoop-4 within the next 12 months would certainly be a big issue for users - especially w.r.t rolling upgrades, wire-compat etc. So, I think we should prioritize these operational aspects for users above everything else. Sure, jdk versions, features etc. are important, but lower in priority. I'd also like to reiterate my concern on *dropping* support for a JDK7 - we need to support it till end of 2015 at the very least; happy to ship a version of Hadoop which is JDK8 only in 2015 - it just needs to support rolling-upgrades from the JDK7 Hadoop till end of 2015. With that in mind... I actually like Andrew's suggestion below: > On Jun 21, 2014, at 8:01 AM, Andrew Wang <andrew.w...@cloudera.com> wrote: > > I'd be more okay with an intermediate release with no incompatible changes > whatsoever besides bumping the JDK requirement to JDK7. Taking that thought to it's logical conclusion, we can de-couple the dual concerns of JDK versions and major releases but bumping up our software dependencies (JDK, guice etc.) at well-defined and well-articulated releases. The reason to so would be to ensure we *do not* sneak in operational incompatibilities in the guise of bumping JDK versions. So, we could do something like: # hadoop-2.30+ is JDK7, but provides rolling upgrades and wire-compat with hadoop-2.2+; say in Oct 2014 # hadoop-2.50+ is JDK8, but provides rolling upgrades and wire-compat with hadoop-2.2+; say in June 2015 (or even earlier). This scheme certainly has some dis-advantages, however it has the significant advantage of making it *very* clear to end-users and administrators that we take operational aspects seriously. Also, this is something we already have done i.e. we updated some of our software deps in hadoop-2.4 v/s hadoop-2.2 - clearly not something as dramatic as JDK. Here are some examples: https://issues.apache.org/jira/browse/HADOOP-9991 https://issues.apache.org/jira/browse/HADOOP-10102 https://issues.apache.org/jira/browse/HADOOP-10103 https://issues.apache.org/jira/browse/HADOOP-10104 https://issues.apache.org/jira/browse/HADOOP-10503 In summary, the key goals we should keep in mind are: # Operational aspects such as rolling upgrades, wire-compat etc. for the next couple of years. # Support JDK7 till end of 2015 at least, even if we decide to support JDK8 sometime in 2015. Just ensure wire-compat, rolling-upgrades etc. Thoughts? thanks, Arun -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
