Hi, 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. Something like this: master (2.0-SNAPSHOT) | | branch-1 (1.1-SNAPSHOT) | | | | branch-1.0 (1.0.1-SNAPSHOT) | | | | | x (1.0.0) | | | | |/ | x (0.99.1) | | | x (0.99.0) | | |/ 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. Enis
