+1 for the 3.0 release plan and continuing 2.x releases.
I'm thinking we should consider stopping new 2.x minor releases after
3.x reaches GA.
Thanks,
Akira
On 2/19/16 10:33, Gangumalla, Uma wrote:
Yes. I think starting 3.0 release with alpha is good idea. So it would get
some time to reach the beta or GA.
+1 for the plan.
For the compatibility purposes and as current stable versions, we should
continue 2.x releases anyway.
Thanks Andrew for starting the thread.
Regards,
Uma
On 2/18/16, 3:04 PM, "Andrew Wang" <andrew.w...@cloudera.com> wrote:
Hi Kihwal,
I think there's still value in continuing the 2.x releases. 3.x comes with
the incompatible bump to a JDK8 runtime, and also the fact that 3.x won't
be beta or GA for some number of months. In the meanwhile, it'd be good to
keep putting out regular, stable 2.x releases.
Best,
Andrew
On Thu, Feb 18, 2016 at 2:50 PM, Kihwal Lee <kih...@yahoo-inc.com.invalid>
wrote:
Moving Hadoop 3 forward sounds fine. If EC is one of the main
motivations,
are we getting rid of branch-2.8?
Kihwal
From: Andrew Wang <andrew.w...@cloudera.com>
To: "common-...@hadoop.apache.org" <common-...@hadoop.apache.org>
Cc: "yarn-...@hadoop.apache.org" <yarn-...@hadoop.apache.org>; "
mapreduce-dev@hadoop.apache.org" <mapreduce-dev@hadoop.apache.org>;
hdfs-dev <hdfs-...@hadoop.apache.org>
Sent: Thursday, February 18, 2016 4:35 PM
Subject: Re: Looking to a Hadoop 3 release
Hi all,
Reviving this thread. I've seen renewed interest in a trunk release
since
HDFS erasure coding has not yet made it to branch-2. Along with JDK8,
the
shell script rewrite, and many other improvements, I think it's time to
revisit Hadoop 3.0 release plans.
My overall plan is still the same as in my original email: a series of
regular alpha releases leading up to beta and GA. Alpha releases make it
easier for downstreams to integrate with our code, and making them
regular
means features can be included when they are ready.
I know there are some incompatible changes waiting in the wings
(i.e. HDFS-6984 making FileStatus a PB rather than Writable, some of
HADOOP-9991 bumping dependency versions) that would be good to get in.
If
you have changes like this, please set the target version to 3.0.0 and
mark
them "Incompatible". We can use this JIRA query to track:
https://issues.apache.org/jira/issues/?jql=project%20in%20(HADOOP%2C%20HD
FS%2C%20YARN%2C%20MAPREDUCE)%20and%20%22Target%20Version%2Fs%22%20%3D%20%
223.0.0%22%20and%20resolution%3D%22unresolved%22%20and%20%22Hadoop%20Flag
s%22%3D%22Incompatible%20change%22%20order%20by%20priority
There's some release-related stuff that needs to be sorted out (namely,
the
new CHANGES.txt and release note generation from Yetus), but I'd
tentatively like to roll the first alpha a month out, so third week of
March.
Best,
Andrew
On Mon, Mar 9, 2015 at 7:23 PM, Raymie Stata <rst...@altiscale.com>
wrote:
Avoiding the use of JDK8 language features (and, presumably, APIs)
means you've abandoned #1, i.e., you haven't (really) bumped the JDK
source version to JDK8.
Also, note that releasing from trunk is a way of achieving #3, it's
not a way of abandoning it.
On Mon, Mar 9, 2015 at 7:10 PM, Andrew Wang <andrew.w...@cloudera.com>
wrote:
Hi Raymie,
Konst proposed just releasing off of trunk rather than cutting a
branch-2,
and there was general agreement there. So, consider #3 abandoned.
1&2
can
be achieved at the same time, we just need to avoid using JDK8
language
features in trunk so things can be backported.
Best,
Andrew
On Mon, Mar 9, 2015 at 7:01 PM, Raymie Stata <rst...@altiscale.com>
wrote:
In this (and the related threads), I see the following three
requirements:
1. "Bump the source JDK version to JDK8" (ie, drop JDK7 support).
2. "We'll still be releasing 2.x releases for a while, with similar
feature sets as 3.x."
3. Avoid the "risk of split-brain behavior" by "minimize
backporting
headaches. Pulling trunk > branch-2 > branch-2.x is already
tedious.
Adding a branch-3, branch-3.x would be obnoxious."
These three cannot be achieved at the same time. Which do we
abandon?
On Mon, Mar 9, 2015 at 12:45 PM, sanjay Radia
<sanjayo...@gmail.com>
wrote:
On Mar 5, 2015, at 3:21 PM, Siddharth Seth <ss...@apache.org>
wrote:
2) Simplification of configs - potentially separating client
side
configs
and those used by daemons. This is another source of perpetual
confusion
for users.
+ 1 on this.
sanjay
