On Wed, Jun 7, 2017 at 10:08 AM, Josh Elser <els...@apache.org> wrote: > > On 6/7/17 11:04 AM, Josh Elser wrote: >> >> >> >> On 6/7/17 1:17 AM, Stack wrote: >>> >>> Lets start in on the hardening of hbase-2.0.0. All features are in though >>> in need of test and polish. There are tasks outstanding around migration >>> from hbase-1 to hbase-2 and narratives to tell our users around timeout, >>> etc. We still need to update dependencies, revamp defaults, etc., but the >>> hbase-2.0.0 countdown has started in earnest. >>> >>> I intend to cut an alpha in the next day or so just so folks can start >>> kicking the tires even though we are a good ways from beta [1]. >>> >>> To be clear, we are done w/ 'features' for hbase-2.0.0. Bug fixes and >>> polish only please from here on out. If you have a borderline item or an >>> item you just can't do w/o, lets discuss. >> >> >> Yay, progress! Thanks for pushing, S. >> >>> I just set the version on master branch to be 3.0.0-SNAPSHOT. >> >> >> I was just thinking about this one this morning: would master become 2.1.0 >> or 3.0.0? >> >> I'd guess that the intent is to put more emphasis on the "x" instead of >> the "y" and "z" (for a version string "x.y.z")? We all on board with that >> plan too, for better or for worse? :) > > > Clarification: I'm really trying to ask the question, should we have a > "branch-2.0" for tracking HBase-2.0.0 instead of a "branch-2"? > > I think trying to avoid multiple, concurrently developed 2.y release lines > would help our sanity (do more 2.y.0 releases, fewer 2.y.z releases), but > that would mean that we're consciously pushing towards a faster cadence for > x.0.0 releases to come. If this is the case, "branch-2" makes sense; > however, if the plan would be to stick with how HBase-1.y.z has been going, > I'd expect a "branch-2.0" (and a "branch-2").
We're now officially replying past each other, so I'm going to slow down. :) creating a branch-2 followed by a branch-2.0 when it's time for 2.0.0 gives us the same structure we have for brnach-1 releases, which IMHO should be our default unless we have a larger community discussion around release emphasis (and I don't think the 2.0 release process should wait for said discusison; branches are cheap). There's been some talk about how we can increase our minor release cadence, but personally I really like how our RM strategy has helped us keep a mostly-good cadence of maintenance releases. Speaking as someone who's done the RM job, I view the maintenance releases as mostly a herding cats exercise. I have to make sure jira and git look sensible, periodically make sure the dummy-lights of our builds.a.o jobs aren't flashing, and then turn the crank to grind through the actual mechanics of a release candidate. If I was doing that for minor releases instead, I'd feel compelled to do more cluster based testing (like I did for the 1.2.0 release) and I don't think I personally have time for that on an ongoing basis.
