After further consideration, here is an alternate.

On Jun 21, 2014, at 11:14 AM, "Arun C. Murthy" <[EMAIL PROTECTED]> wrote:
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:
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:

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.


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.

NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB