> Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still > have the issue of things committed for 2.9.0 that will be appearing for the > first time in 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs, > it's only incrementally more work to also fix up 2.8 and other unreleased > versions too.
This. this is why I've been a bit confused on folks not wanting to invest the time in getting multiple major branches working correctly. With my "Hadoop community" hat on, I see that we struggle with maintaining multiple maintenance lines just within 2.y and I worry how we're going to do once 3.y is going. With my downstream "HBase community" hat on, I'm pretty sure I still need there to still be 2.y releases. AFAIK the HBase community hasn't made any plans to e.g. abandon Hadoop 2.y versions in our next major release and we'd be very sad if all future features we needed added to e.g. HDFS forced our users to upgrade across a major version. On Thu, Jul 21, 2016 at 2:33 PM, Andrew Wang <andrew.w...@cloudera.com> wrote: > I really, really want a 3.0.0-alpha1 ASAP, since it's basically impossible > for downstreams to test incompat changes and new features without a release > artifact. I've been doing test builds, and branch-3.0.0-alpha1 is ready for > an RC besides possibly this fix version issue. > > I'm not too worried about splitting community bandwidth, for the following > reasons: > > * 3.0.0-alpha1 is very explicitly an alpha, which means no quality or > compatibility guarantees. It needs less vetting than a 2.x release. > * Given that 3.0.0 is still in alpha, there aren't many true showstopper > bugs. Most blockers I see are also apply to both 2.x as well as 3.0.0. > * Community bandwidth isn't zero-sum. This particularly applies to people > working on features that are only present in trunk, like EC, shell script > rewrite, etc. > > Longer-term, I assume the 2.x line is not ending with 2.8. So we'd still > have the issue of things committed for 2.9.0 that will be appearing for the > first time in 3.0.0-alpha1. Assuming a script exists to fix up 2.9 JIRAs, > it's only incrementally more work to also fix up 2.8 and other unreleased > versions too. > > Best, > Andrew > > On Thu, Jul 21, 2016 at 11:53 AM, Vinod Kumar Vavilapalli < > vino...@apache.org> wrote: > >> The L & N fixes just went out, I’m working to push out 2.7.3 - running >> into a Nexus issue. Once that goes out, I’ll immediately do a 2.8.0. >> >> Like I requested before in one of the 3.x threads, can we just line up >> 3.0.0-alpha1 right behind 2.8.0? >> >> That simplifies most of this confusion, we can avoid splitting the >> bandwidth from the community on fixing blockers / vetting these concurrent >> releases. Waiting a little more for 3.0.0 alpha to avoid most of this is >> worth it, IMO. >> >> Thanks >> +Vinod >> >> > On Jul 21, 2016, at 11:34 AM, Andrew Wang <andrew.w...@cloudera.com> >> wrote: >> > >> > Hi all, >> > >> > Since we're planning to spin releases off of both branch-2 and trunk, the >> > changelog for 3.0.0-alpha1 based on JIRA information isn't accurate. This >> > is because historically, we've only set 2.x fix versions, and 2.8.0 and >> > 2.9.0 and etc have not been released. So there's a whole bunch of changes >> > which will show up for the first time in 3.0.0-alpha1. >> > >> > I think I can write a script to (carefully) add 3.0.0-alpha1 to these >> > JIRAs, but I figured I'd give a heads up here in case anyone felt >> > differently. I can also update the HowToCommit page to match. >> > >> > Thanks, >> > Andrew >> >> -- busbey --------------------------------------------------------------------- To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: common-dev-h...@hadoop.apache.org
