While we haven't codified this in our compatibility guidelines, dropping a
Java version seems to me like change that needs to happen alongside a major
release.  In plain talk, it has the ability to break everything for users
who aren't doing anything particularly unreasonable.

I don't think we should accept Hadoop's compatibility behavior 6 years ago
as precedent for what we can do now. That was before Hadoop 1.0. And we
probably have several orders of magnitude more production users.

I also don't think we should accept library upgrades as precedent.  While
this may make sense in specific situations, I definitely don't think this
is OK in general.  I'd be very nervous about updating Guava outside of
major version upgrade.

Lastly, I think the claim that nobody is running in production on Java 6 is

We need to think about a JDK upgrade in terms of what its implications are
for users, not in terms of what other kinds of compatibility we've broken
that's loosely analogous.


On Tue, Jun 24, 2014 at 3:42 PM, Vinod Kumar Vavilapalli <[EMAIL PROTECTED]
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