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