On Tue, Sep 4, 2012 at 11:55 AM, Owen O'Malley <omal...@apache.org> wrote: > While cleaning up the subversion branches, I thought more about the > branch 2 release names. I'm concerned if we backtrack and reuse > release numbers it will be extremely confusing to users. It also > creates problems for tools like Maven that parse version numbers and > expect a left to right release numbering scheme (eg. 2.1.1-alpha > > 2.1.0). It also seems better to keep on the 2.0.x minor release until > after we get a GA release off of the 2.0 branch. > > Therefore, I'd like to propose: > 1. rename branch-2.0.1-alpha -> branch-2.0 > 2. delete branch-2.1.0-alpha > 3. stabilizing goes into branch-2.0 until it gets to GA > 4. features go into branch-2 and will be branched into branch-2.1 later > 5. The release tags can have the alpha/beta tags on them. > > Thoughts? >
branch-2.0.1-alpha is pretty far behind branch-2 at this point, both in terms of features merged to branch-2 (eg no auto failover or hsync) and bug fixes (iiuc it is just 2.0 plus a couple changes). From my hdfs pov the branch doesn't seem worth maintaining. I'd tweak this as follows: 1. delete branch-2.1.0-alpha 2. rename branch-2 -> branch-2.0 some time after 0.23.3 is released 3. stabilizing goes into branch-2.0 until it gets to GA 4. features go into branch-2 and will be branched into branch-2.1 later 5. The release tags can have the alpha/beta tags on them. On the hdfs side most trunk work is for branch-2 so we're already merging trunk -> branch-2, so delaying the third merge would help, and we're using feature branches for the big stuff (HDFS-3077) so they're being isolated that way. Thanks, Eli
