hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <els...@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:30:42 GMT

On 6/7/17 11:15 AM, Sean Busbey wrote:
> 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. :)

/me smiles

> 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).

Gotcha! Your other email (with the 4-5 steps) clarified this well.

> 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.

Understood. I just realized that I wasn't sure if the intention was for 
HBase-2 releases to follow the same "train" as HBase-1 releases. Given 
the struggle to just slow down master to make branch-2 was hard -- I 
couldn't have said if there was a bigger goal ongoing to try to avoid 
that for the eventual branch-3.

View raw message