On Tue, Sep 4, 2012 at 11:55 AM, Owen O'Malley <[EMAIL PROTECTED]> 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.
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
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.