+1 with approach B Cheers
On Tue, Jun 10, 2014 at 2:26 PM, Jonathan Hsieh <[email protected]> wrote: > +1 for approach B/#2. and +1 for 0.99 versions. > > Jon. > > > On Tue, Jun 10, 2014 at 2:07 PM, Enis Söztutar <[email protected]> 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 > > > > > > -- > // Jonathan Hsieh (shay) > // HBase Tech Lead, Software Engineer, Cloudera > // [email protected] // @jmhsieh >
