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:08:53 GMT

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

View raw message