As per previous threads, I am planning to branch out 1.0 at Jun 23, Mon. It will include the changes committed as of that date. HBASE-10070 merge should be completed as well. We can have the meta-based assignment as well. Branching now, versus after we do 0.99.0 release gives us the chance to stabilize the branch for the release.
I am aiming for having a 0.99.0RC0 out by end of June, do one or more 0.99.x releases in July and having 1.0.0RC0 by Aug or so.
I think for branching we can do two approaches:
a) create a branch named "1.0". Change the master branch version to be 1.1-SNAPSHOT. This implies that master branch cannot have any breaking changes until we branch for 2.0. If we do not need it, this will be simpler.
Something like this: master (1.1-SNAPSHOT) | | 1.0 (1.0-SNAPSHOT) | | | x (1.0.0) | | | x (0.99.1) | | | x (0.99.0) | | |/
b) create a branch named "branch-1". Change the master branch version to be 2.0-SNAPSHOT. This implies that all patches that are intended for 1.x series will go to branch-1, and all 1.x releases will be branched off of branch-1. Also branch-1.0 will be branched from branch-1.
In both of these plans, 0.99.xRCs will come out of the branch for 1.
After we branched, we will only accept patches relevant to 1.0 release. In that respect, it won't be a feature freeze, but we will selectively backport features that we think would be needed for 1.0. Main candidates are the subtasks / linked issues in https://issues.apache.org/jira/browse/HBASE-10856. Some of the issues there still lacks some love, so I am not sure whether they will be done in time. If not, we do not have any choice but to kick them out by the time 1.0 comes. Everything still goes to master first.
Let me know what you guys think. Any alternate proposals? Which one we should do? I am more in favor of b) which will be the most flexible route to having true semantic versioning for the cost of added branch complexity. a) should be fine as well if we are fine with lazy branching for 2.0.
On Tue, Jun 10, 2014 at 3:28 PM, Konstantin Boudnik <[EMAIL PROTECTED]> wrote: Its not done and it is far along with Mikhail making good progress. I'd be up for keeping up reviews and commit (if thats OK w/ you Mr. RM).
How much you think could make 1.0 Cos/Mikhail? Which issues.
I think jiras on ZK abstraction can still get committed (I'll make sure to have all non-trivial patches posted on RB for discussion to make sure we don't accidentally introduce any instability).
Under HBASE-10909: - HBASE-11069 (region merge transaction) is close to completion, just needs rebasing/merging, so we should have the new patch soon - HBASE-11072 (WAL splitting) - there's progress going on here, I think we're going to have patch up for reviews pretty soon. - HBASE-11073 (abstract Zk Watcher and listeners) - should have first patch up for review in a week or two
Besides that, we should have HBASE-4495 (get rid of CatalogTracker) too.
Further steps on abstraction (involving changing/simplifying the way we keep state in ZK) require coordination engine (as described in consensus design doc), which has been proposed in hadoop-common (for the time being I guess we can add this engine directly to HBase to speedup development?).
Mikhail 2014-06-10 15:46 GMT-07:00 Stack <[EMAIL PROTECTED]>: Thanks, Michael Antonov
I am +1 on b) because it will naturally allow for a continuation of 1.x development.
In all honesty, I found that notorious git branching model works perfectly for such situations. One thing to mention: unlike http://nvie.com/posts/a-successful-git-branching-model/ it'll force a significant number of cherry-picking from the master (and SHA1 changes on such commits). Perhaps it might be a good time to reconsider what has been working ok for Hadoop on SVN and look into something that's more natural for Git branching?
On Tue, Jun 10, 2014 at 07:16PM, Jean-Marc Spaggiari wrote: