hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@hortonworks.com>
Subject Re: [DISCUSS] A final minor release off branch-2?
Date Wed, 08 Nov 2017 11:57:25 GMT

> On 7 Nov 2017, at 19:08, Vinod Kumar Vavilapalli <vinodkv@apache.org> wrote:
>> Frankly speaking, working on some bridging release not targeting any feature isn't
so attractive to me as a contributor. Overall, the final minor release off branch-2 is good,
we should also give 3.x more time to evolve and mature, therefore it looks to me we would
have to work on two release lines meanwhile for some time. I'd like option C), and suggest
we focus on the recent releases.
> Answering this question is also one of the goals of my starting this thread. Collectively
we need to conclude if we are okay or not okay with no longer putting any new feature work
in general on the 2.x line after 2.9.0 release and move over our focus into 3.0.
> Thanks
> +Vinod

As a developer of new features (e.g the Hadoop S3A committers), I'm mostly already committed
to targeting 3.1; the code in there to deal with failures and retries has unashamedly embraced
java 8 lambda-expressions in production code: backporting that is going to be traumatic in
terms of IDE-assisted code changes and the resultant diff in source between branch-2 &
trunk. What's worse, its going to be traumatic to test as all my JVMs start with an 8 at the
moment, and I'm starting to worry about whether I should bump a windows VM up to Java 9 to
keep an eye on Akira's work there. Currently the only testing I'm really doing on java 7 is
yetus branch-2 & internal test runs.

3.0 will be out the door, and we can assume that CDH will ship with it soon (*)  which will
allow for a rapid round trip time on inevitable bugs: 3.1 can be the release with compatibility
tuned, those reported issues addressed. It's certainly where I'd like to focus.

At the same time: 2.7.2-2.8.x are the broadly used versions, we can't just say "move to 3.0"
& expect everyone to do it, not given we have explicitly got backwards-incompatible changes
in. I don't seen people rushing to do it until the layers above are all qualified (HBase,
Hive, Spark, ...). Which means big users of 2.7/2,8 won't be in a rush to move and we are
going to have to maintain 2.x for a while, including security patches for old versions. One
issue there: what if a patch (such as bumping up a JAR version) is incompatible?

For me then

* 3.1+ for new features
* fixes to 3.0.x &, where appropriate, 2.9, esp feature stabilisation
* whoever puts their hand up to do 2.x releases deserves support in testing &c
* If someone makes a really strong case to backport a feature from 3.x to branch-2 and its
backwards compatible, I'm not going to stop them. It's just once 3.0 is out and a 3.1 on the
way, it's less compelling


Note: I'm implicitly assuming a timely 3.1 out the door with my work included, all all issues
arriving from 3,0 fixed. We can worry when 3.1 ships whether there's any benefit in maintaining
a 3.0.x, or whether it's best to say "move to 3.1"

(*) just a guess based the effort & test reports of Andrew & others

To unsubscribe, e-mail: mapreduce-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: mapreduce-dev-help@hadoop.apache.org

View raw message