hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@apache.org>
Subject Re: NOTICE: I just created branch-2, the branch from where we'll cut hbase-2.0.0
Date Wed, 07 Jun 2017 15:15:47 GMT
On Wed, Jun 7, 2017 at 10:08 AM, Josh Elser <elserj@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.

View raw message