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
unsubstantiated.

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.

-Sandy

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