While cleaning up the subversion branches, I thought more about thebranch 2 release names. I'm concerned if we backtrack and reuserelease numbers it will be extremely confusing to users. It alsocreates problems for tools like Maven that parse version numbers andexpect 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 untilafter 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.02. delete branch-2.1.0-alpha3. stabilizing goes into branch-2.0 until it gets to GA4. features go into branch-2 and will be branched into branch-2.1 later5. The release tags can have the alpha/beta tags on them.

+1 for moving on with 2.0 till it gets GA'ed, given we haven't made much progress on 2.0.1-alpha.

+1 for putting the alpha/beta tags only on releases, and not on branches.

This also reduces some branch-clutter like I mentioned on the other thread on general@h.a.o.

Thanks,+Vinod

On Sep 4, 2012, at 11:55 AM, Owen O'Malley 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?> > -- Owen

I am fine with that too, but it is going to be a fairly large amount ofwork to pull in all of the bug fixes into 2.0 that have gone into 0.23.There was already a lot of discussion about just rebasing 2.1 instead oftrying to merge everything back into it and 2.1 is a lot further alongthen 2.0 is. Just something to be aware of.

>>+1 for moving on with 2.0 till it gets GA'ed, given we haven't made much>progress on 2.0.1-alpha.>>+1 for putting the alpha/beta tags only on releases, and not on branches.>>This also reduces some branch-clutter like I mentioned on the other>thread on general@h.a.o.>>Thanks,>+Vinod>>On Sep 4, 2012, at 11:55 AM, Owen O'Malley 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?>> >> -- Owen>

> I am fine with that too, but it is going to be a fairly large amount of> work to pull in all of the bug fixes into 2.0 that have gone into 0.23.> There was already a lot of discussion about just rebasing 2.1 instead of> trying to merge everything back into it and 2.1 is a lot further along> then 2.0 is. Just something to be aware of.> > --Bobby Evans

I am fine with that too, but it is going to be a fairly large amount ofwork to pull in all of the bug fixes into 2.0 that have gone into 0.23.There was already a lot of discussion about just rebasing 2.1 instead oftrying to merge everything back into it and 2.1 is a lot further alongthen 2.0 is. Just something to be aware of.

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.>> Thoughts?>

branch-2.0.1-alpha is pretty far behind branch-2 at this point, bothin 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 myhdfs pov the branch doesn't seem worth maintaining. I'd tweak this asfollows:

1. delete branch-2.1.0-alpha2. rename branch-2 -> branch-2.0 some time after 0.23.3 is released3. stabilizing goes into branch-2.0 until it gets to GA4. features go into branch-2 and will be branched into branch-2.1 later5. 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 alreadymerging trunk -> branch-2, so delaying the third merge would help, andwe're using feature branches for the big stuff (HDFS-3077) so they'rebeing isolated that way.

> 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.> >> > Thoughts?>

On Wed, Sep 5, 2012 at 11:04 AM, Andrew Purtell <[EMAIL PROTECTED]> wrote:> If it's all the same to you, I'd prefer you leave the branch, or at least a> tag, and just ignore it. We're pretty far away from branch-2.1.0 following> branch-2 but started from that point.

Subversion you don't actually ever delete anything. For example, I'vedeleted the branch-0.20-append, but you can still get it from:

> On Wed, Sep 5, 2012 at 11:04 AM, Andrew Purtell <[EMAIL PROTECTED]>> wrote:> > If it's all the same to you, I'd prefer you leave the branch, or at> least a> > tag, and just ignore it. We're pretty far away from branch-2.1.0> following> > branch-2 but started from that point.>> Subversion you don't actually ever delete anything. For example, I've> deleted the branch-0.20-append, but you can still get it from:>> % svn ls> https://svn.apache.org/repos/asf/hadoop/common/branches/branch-0.20-append@1380308>> Given that would you like a dev branch (hbase-branch-2.0?)?>> -- Owen>

For now, I think we can delete branch-2.1.0-alpha, create branch-2.0.2-alpha release off branch-2 and eventually make branch-2.1.0 as the stable release in the future.

Arun

On Sep 4, 2012, at 11:55 AM, Owen O'Malley 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?> > -- Owen

> Sounds fine.> > For now, I think we can delete branch-2.1.0-alpha, create branch-2.0.2-alpha release off branch-2 and eventually make branch-2.1.0 as the stable release in the future.> > Arun> > On Sep 4, 2012, at 11:55 AM, Owen O'Malley 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?>> >> -- Owen> > --> Arun C. Murthy> Hortonworks Inc.> http://hortonworks.com/> >

To be clear, I think we all seem to agree that we continue to make hadoop-2.0.3, hadoop-2.0.3 etc. with alpha/beta tags as appropriate until we git 'GA' at which point we release hadoop-2.1.0. Makes sense?

thanks,Arun

On Sep 6, 2012, at 11:38 AM, Arun C Murthy wrote:

> Uh, I meant 'create hadoop-2.0.2-alpha' release off branch-2.> > On Sep 6, 2012, at 11:18 AM, Arun C Murthy wrote:> >> Sounds fine.>> >> For now, I think we can delete branch-2.1.0-alpha, create branch-2.0.2-alpha release off branch-2 and eventually make branch-2.1.0 as the stable release in the future.>> >> Arun>> >> On Sep 4, 2012, at 11:55 AM, Owen O'Malley 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?>>> >>> -- Owen>> >> -->> Arun C. Murthy>> Hortonworks Inc.>> http://hortonworks.com/>> >> > > --> Arun C. Murthy> Hortonworks Inc.> http://hortonworks.com/> >