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

+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  

On 9/4/12 2:19 PM, "Vinod Kumar Vavilapalli" <[EMAIL PROTECTED]>
wrote:

>
>+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
>

May be you misread the proposal. This is only about nuking 2.1.0-alpha and wait for 0.23.3 to be stabilized and released. Once that happens, we can create a branch-2.1 off branch-2.

Does that sound okay?

Thanks,
+Vinod Kumar Vavilapalli
Hortonworks Inc.
http://hortonworks.com/

On Sep 4, 2012, at 3:05 PM, Robert Evans wrote:

> 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 must have misread it.  Thanks for clarifying.

--Bobby

From: Vinod Kumar Vavilapalli <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>>
Reply-To: "[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>" <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>>
Date: Tuesday, September 4, 2012 7:29 PM
To: "[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>" <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>>
Subject: Re: Branch 2 release names

May be you misread the proposal. This is only about nuking 2.1.0-alpha and wait for 0.23.3 to be stabilized and released. Once that happens, we can create a branch-2.1 off branch-2.

Does that sound okay?

Thanks,
+Vinod Kumar Vavilapalli
Hortonworks Inc.
http://hortonworks.com/

On Sep 4, 2012, at 3:05 PM, Robert Evans wrote:

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

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, 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

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.

On Wed, Sep 5, 2012 at 8:52 AM, Eli Collins <[EMAIL PROTECTED]> wrote:

> 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'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

No, thanks Owen.

On Thu, Sep 6, 2012 at 9:27 AM, Owen O'Malley <[EMAIL PROTECTED]> wrote:

> 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
>

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/

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/

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/
>
>

--
Arun C. Murthy
Hortonworks Inc.
http://hortonworks.com/