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