To follow up on my earlier email, I don't think there's need for a bridge release given that we've successfully tested rolling upgrade from 2.x to 3.0.0. I expect we'll keep making improvements to smooth over any additional incompatibilities found, but there isn't a requirement that a user upgrade to a bridge release before upgrading to 3.0.
Otherwise, I don't have a strong opinion about when to discontinue branch-2 releases. Historically, a release line is maintained until interest in it wanes. If the maintainers are taking care of the backports, it's not much work for the rest of us to vote on the RCs. Best, Andrew On Mon, Nov 13, 2017 at 4:19 PM, Wangda Tan <wheele...@gmail.com> wrote: > 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 >> >> >
