> 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: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
