Thanks Vinod for staring this, I'm also leaning towards the plan (A):
* (A) -- Make 2.9.x the last minor release off branch-2 -- Have a maintenance release that bridges 2.9 to 3.x -- Continue to make more maintenance releases on 2.8 and 2.9 as necessary* The only part I'm not sure is having a separate bridge release other than 3.x. For the bridge release, Steve's suggestion sounds more doable: ** 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* This makes community can focus on 3.x releases and fill whatever gaps of migrating from 2.x to 3.x. Best, Wangda On Wed, Nov 8, 2017 at 3:57 AM, Steve Loughran <ste...@hortonworks.com> wrote: > > > On 7 Nov 2017, at 19:08, Vinod Kumar Vavilapalli <vino...@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 > > -Steve > > 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-unsubscr...@hadoop.apache.org > For additional commands, e-mail: mapreduce-dev-h...@hadoop.apache.org > >
