+1 on the #2. One question though: do you envision that the work around coordinated replication won't be able to go into branch-1 anymore?
Thanks, Cos On Tue, Jun 10, 2014 at 02:07PM, Enis Söztutar wrote: > 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
