hadoop-hdfs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arun C Murthy <...@hortonworks.com>
Subject Re: Plans of moving towards JDK7 in trunk
Date Sun, 22 Jun 2014 00:59:21 GMT

After further consideration, here is an alternate.

On Jun 21, 2014, at 11:14 AM, "Arun C. Murthy" <acm@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.wang@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message