Please vote on naming 'future' releases off branch-0.20-security (with
both security & append) as hadoop-1.x.x.

We should also rename branch-0.20-security as branch-1.x.x.

I propose we use the common 3-part major, minor (compatible, newer
features) and sub-minor (bug fixes) scheme as suggested by Doug in the
previous thread.

The vote will run the normal 5 days.

thanks,
Arun

+1

My preference is to call it 1.0 and not as 1.6 to reflect 0.20.206.
On Nov 15, 2011, at 8:22 PM, Arun Murthy <[EMAIL PROTECTED]> wrote:

> Please vote on naming 'future' releases off branch-0.20-security (with
> both security & append) as hadoop-1.x.x.
>
> We should also rename branch-0.20-security as branch-1.x.x.
>
> I propose we use the common 3-part major, minor (compatible, newer
> features) and sub-minor (bug fixes) scheme as suggested by Doug in the
> previous thread.
>
> The vote will run the normal 5 days.
>
> thanks,
> Arun

+1 (non-binding)

Let's ship 1.0.0 off 0.20.205.*

I think this will be great for the project.

Arun, since you called the vote, can you clarify exactly what version of the 20.2xx.x line will be renamed or originally released as exactly what 1.0.x version?  It seems like following versions will take care of themselves, but let's vote on a specific action.  

On Nov 15, 2011, at 9:15 PM, Suresh Srinivas wrote:

> +1
>
> My preference is to call it 1.0 and not as 1.6 to reflect 0.20.206.
>
>
> On Nov 15, 2011, at 8:22 PM, Arun Murthy <[EMAIL PROTECTED]> wrote:
>
>> Please vote on naming 'future' releases off branch-0.20-security (with
>> both security & append) as hadoop-1.x.x.
>>
>> We should also rename branch-0.20-security as branch-1.x.x.
>>
>> I propose we use the common 3-part major, minor (compatible, newer
>> features) and sub-minor (bug fixes) scheme as suggested by Doug in the
>> previous thread.
>>
>> The vote will run the normal 5 days.
>>
>> thanks,
>> Arun

So, does this mean then any 2.x.x release will have *all* of the features
of the 1.x.x ?  Anything not in there should be deprecated, right?

If not, then it is not really linear as most software projects are
providing versions that have new features on top of the support for
previous ones.

I am hard pressed to think of any software release ever where a feature
that folks want ONLY exists in a previous version. I might be off base here
as the trunk might represent the ALL of the features in this branch????

So if 2.x.x will have security, append (and all of the other goodies that
are in 1.x.x) then it makes sense otherwise it is just as confusing but
just re-labled.

Sorry, trying to get a grasp of all of this seems to be moving quickly and
not sure if the branch / trunk is merging or just being re-labeled for *
marketing* purposes.

If I am having confusion then confusion will come further from folks trying
to get into Hadoop also.  Just saying.

All of the good work that everyone has done is awesome, just trying to
understand some straight line path of releases.   This is not a new idea
and typical of what the software community as a whole expects (speaking for
the 99%).  If 0.23 trunk release is a representation of the branch release
0.20.20X.X with all of the patches there, then fantastic but have not heard
that mentioned (and honestly it is very hard to keep track).

any clarity would be helpful, thanx
On Wed, Nov 16, 2011 at 1:43 AM, Eric Baldeschwieler <[EMAIL PROTECTED]
> wrote:

> +1 (non-binding)
>
> Let's ship 1.0.0 off 0.20.205.*
>
> I think this will be great for the project.
>
> Arun, since you called the vote, can you clarify exactly what version of
> the 20.2xx.x line will be renamed or originally released as exactly what
> 1.0.x version?  It seems like following versions will take care of
> themselves, but let's vote on a specific action.
>
>
>
> On Nov 15, 2011, at 9:15 PM, Suresh Srinivas wrote:
>
> > +1
> >
> > My preference is to call it 1.0 and not as 1.6 to reflect 0.20.206.
> >
> >
> > On Nov 15, 2011, at 8:22 PM, Arun Murthy <[EMAIL PROTECTED]> wrote:
> >
> >> Please vote on naming 'future' releases off branch-0.20-security (with
> >> both security & append) as hadoop-1.x.x.
> >>
> >> We should also rename branch-0.20-security as branch-1.x.x.
> >>
> >> I propose we use the common 3-part major, minor (compatible, newer
> >> features) and sub-minor (bug fixes) scheme as suggested by Doug in the
> >> previous thread.
> >>
> >> The vote will run the normal 5 days.
> >>
> >> thanks,
> >> Arun
>
>
--

/*
Joe Stein
http://www.linkedin.com/in/charmalloc
Twitter: @allthingshadoop <http://twitter.com/#!/allthingshadoop>
*/

I don't think we should vote it that way.
Because 0.23 and 0.22 become confusing in this case.
Unless you want to replace trunk with what is in 0.20.205.

The three branches 0.20.security, o.22, and 0.23 have very different
codes bases. So calling them 1, 2, and 3 respectively is natural.
But we should vote on a complex naming convention, not just the thing
which will be called Hadoop 1.
And try to make it less confusing for the users.

Thanks,
--Konstantin

On Tue, Nov 15, 2011 at 10:43 PM, Eric Baldeschwieler
<[EMAIL PROTECTED]> wrote:
> +1 (non-binding)
>
> Let's ship 1.0.0 off 0.20.205.*
>
> I think this will be great for the project.
>
> Arun, since you called the vote, can you clarify exactly what version of the 20.2xx.x line will be renamed or originally released as exactly what 1.0.x version?  It seems like following versions will take care of themselves, but let's vote on a specific action.
>
>
>
> On Nov 15, 2011, at 9:15 PM, Suresh Srinivas wrote:
>
>> +1
>>
>> My preference is to call it 1.0 and not as 1.6 to reflect 0.20.206.
>>
>>
>> On Nov 15, 2011, at 8:22 PM, Arun Murthy <[EMAIL PROTECTED]> wrote:
>>
>>> Please vote on naming 'future' releases off branch-0.20-security (with
>>> both security & append) as hadoop-1.x.x.
>>>
>>> We should also rename branch-0.20-security as branch-1.x.x.
>>>
>>> I propose we use the common 3-part major, minor (compatible, newer
>>> features) and sub-minor (bug fixes) scheme as suggested by Doug in the
>>> previous thread.
>>>
>>> The vote will run the normal 5 days.
>>>
>>> thanks,
>>> Arun
>
>

To be specific (both Eli and Eric pointed this) I'd like to clarify
that we should call the upcoming 0.20.205.1 as 1.0.0 - this is in
keeping with the 'look forward' theme.

thanks,
Arun
On Nov 15, 2011, at 8:22 PM, Arun Murthy <[EMAIL PROTECTED]> wrote:

> Please vote on naming 'future' releases off branch-0.20-security (with
> both security & append) as hadoop-1.x.x.
>
> We should also rename branch-0.20-security as branch-1.x.x.
>
> I propose we use the common 3-part major, minor (compatible, newer
> features) and sub-minor (bug fixes) scheme as suggested by Doug in the
> previous thread.
>
> The vote will run the normal 5 days.
>
> thanks,
> Arun

+1 for calling 0.20.205.1 as 1.0.0.

mahadev

On Tue, Nov 15, 2011 at 11:08 PM, Arun Murthy <[EMAIL PROTECTED]> wrote:
> To be specific (both Eli and Eric pointed this) I'd like to clarify
> that we should call the upcoming 0.20.205.1 as 1.0.0 - this is in
> keeping with the 'look forward' theme.
>
> thanks,
> Arun
>
>
> On Nov 15, 2011, at 8:22 PM, Arun Murthy <[EMAIL PROTECTED]> wrote:
>
>> Please vote on naming 'future' releases off branch-0.20-security (with
>> both security & append) as hadoop-1.x.x.
>>
>> We should also rename branch-0.20-security as branch-1.x.x.
>>
>> I propose we use the common 3-part major, minor (compatible, newer
>> features) and sub-minor (bug fixes) scheme as suggested by Doug in the
>> previous thread.
>>
>> The vote will run the normal 5 days.
>>
>> thanks,
>> Arun
>

On 16/11/11 04:22, Arun Murthy wrote:
> Please vote on naming 'future' releases off branch-0.20-security (with
> both security&  append) as hadoop-1.x.x.
>
> We should also rename branch-0.20-security as branch-1.x.x.
>
> I propose we use the common 3-part major, minor (compatible, newer
> features) and sub-minor (bug fixes) scheme as suggested by Doug in the
> previous thread.
>
> The vote will run the normal 5 days.
>
> thanks,
> Arun

-1

I feel this numbering scheme runs the risk of going like Firefox -what
is it this week? And how traumatic will it be from upgrading from last
week's firefox version?
0.20.x is the primary platform people use today
0.20.20x is the latest ASF version of that, though I don't know it's
in-field takeup

* keeping it as 0.20.x would tell people that if they are running
0.20.x, the cost of upgrading would be less

* having a 1.0 and 2.0 release in roughly the same timeframe will
generate more confusion as to the future roadmap.

If 0.23 -> 2.0 (as everyone agrees) then that will send a clear message
to users that
  -this is a major release with major new features
  -it is the way forward

Keeping the 0.20.x numbering for that branch makes it clear that is the
maintenance branch for people who aren't upgrading.

On Wed, Nov 16, 2011 at 10:22AM, Steve Loughran wrote:
> On 16/11/11 04:22, Arun Murthy wrote:
>> Please vote on naming 'future' releases off branch-0.20-security (with
>> both security&  append) as hadoop-1.x.x.
>>
>> We should also rename branch-0.20-security as branch-1.x.x.
>>
>> I propose we use the common 3-part major, minor (compatible, newer
>> features) and sub-minor (bug fixes) scheme as suggested by Doug in the
>> previous thread.
>>
>> The vote will run the normal 5 days.
>>
>> thanks,
>> Arun
>
> -1
>
> If 0.23 -> 2.0 (as everyone agrees) then that will send a clear message  
> to users that

Sorry, Steve - not everyone agrees with that apparently. And the reason for
said disagreement has been discussed in lengths times and again.

There are three major development branches in existence and if re-numbering
takes place than all three should be considered equally to prevent creating
even more mess with the versions. What you are proposing will essentially lead to

    0.22  -> 0.22
    0.20+ -> 1.0
    0.23  -> 2.0

And this will be so bad that frequent Firefox major version updates (which
works great, btw) will look like a nice thing to have.

Cos

+1 for release future 2xx releases as 1.x.y.

I believe the right mapping is:
rename branch-0.20-security to branch-1
copy branch-0.20-security-205 to branch-1.0

Then the 1.0.x releases will come off of the branch-1.0 and branch-1 will
be the upcoming 1.1.x releases.

-- Owen

+1

On Wed, Nov 16, 2011 at 4:49 PM, Owen O'Malley <[EMAIL PROTECTED]> wrote:
> +1 for release future 2xx releases as 1.x.y.
>
> I believe the right mapping is:
> rename branch-0.20-security to branch-1
> copy branch-0.20-security-205 to branch-1.0
>
> Then the 1.0.x releases will come off of the branch-1.0 and branch-1 will
> be the upcoming 1.1.x releases.
>
> -- Owen
>

Let me repeat. By renaming ONLY 0.20.security to 1.0
you are replacing Hadoop-trunk with this branch.
Is that the intention of the rename?
Are we switching to the security branch as the new trunk?

--Konstantin

On Wed, Nov 16, 2011 at 11:48 PM, Eric Yang <[EMAIL PROTECTED]> wrote:
> +1
>
> On Wed, Nov 16, 2011 at 4:49 PM, Owen O'Malley <[EMAIL PROTECTED]> wrote:
>> +1 for release future 2xx releases as 1.x.y.
>>
>> I believe the right mapping is:
>> rename branch-0.20-security to branch-1
>> copy branch-0.20-security-205 to branch-1.0
>>
>> Then the 1.0.x releases will come off of the branch-1.0 and branch-1 will
>> be the upcoming 1.1.x releases.
>>
>> -- Owen
>>
>

Nope, just change the version number of releases off this branch.

Trunk continues to be trunk. 0.23 or 0.24 etc. etc. whatever we choose to call them come off trunk.

This is about one branch only.

Arun

On Nov 17, 2011, at 7:29 PM, Konstantin Shvachko wrote:

> Let me repeat. By renaming ONLY 0.20.security to 1.0
> you are replacing Hadoop-trunk with this branch.
> Is that the intention of the rename?
> Are we switching to the security branch as the new trunk?
>
> --Konstantin
>
>
>
> On Wed, Nov 16, 2011 at 11:48 PM, Eric Yang <[EMAIL PROTECTED]> wrote:
>> +1
>>
>> On Wed, Nov 16, 2011 at 4:49 PM, Owen O'Malley <[EMAIL PROTECTED]> wrote:
>>> +1 for release future 2xx releases as 1.x.y.
>>>
>>> I believe the right mapping is:
>>> rename branch-0.20-security to branch-1
>>> copy branch-0.20-security-205 to branch-1.0
>>>
>>> Then the 1.0.x releases will come off of the branch-1.0 and branch-1 will
>>> be the upcoming 1.1.x releases.
>>>
>>> -- Owen
>>>
>>

Doesn't having trunk on lesser version than a branch make Hadoop
versioning more confusing?
People were asking for consistent non-confusing versioning schema.
Why don't we instead call a vote on your initial suggestion lately
clarified by Matt?
I got a feeling many are in favor of it.

--Konstantin

On Fri, Nov 18, 2011 at 10:20 AM, Arun C Murthy <[EMAIL PROTECTED]> wrote:
> Nope, just change the version number of releases off this branch.
>
> Trunk continues to be trunk. 0.23 or 0.24 etc. etc. whatever we choose to call them come off trunk.
>
> This is about one branch only.
>
> Arun
>
> On Nov 17, 2011, at 7:29 PM, Konstantin Shvachko wrote:
>
>> Let me repeat. By renaming ONLY 0.20.security to 1.0
>> you are replacing Hadoop-trunk with this branch.
>> Is that the intention of the rename?
>> Are we switching to the security branch as the new trunk?
>>
>> --Konstantin
>>
>>
>>
>> On Wed, Nov 16, 2011 at 11:48 PM, Eric Yang <[EMAIL PROTECTED]> wrote:
>>> +1
>>>
>>> On Wed, Nov 16, 2011 at 4:49 PM, Owen O'Malley <[EMAIL PROTECTED]> wrote:
>>>> +1 for release future 2xx releases as 1.x.y.
>>>>
>>>> I believe the right mapping is:
>>>> rename branch-0.20-security to branch-1
>>>> copy branch-0.20-security-205 to branch-1.0
>>>>
>>>> Then the 1.0.x releases will come off of the branch-1.0 and branch-1 will
>>>> be the upcoming 1.1.x releases.
>>>>
>>>> -- Owen
>>>>
>>>
>
>

On Fri, Nov 18, 2011 at 04:30PM, Konstantin Shvachko wrote:
> Doesn't having trunk on lesser version than a branch make Hadoop
> versioning more confusing?
> People were asking for consistent non-confusing versioning schema.
> Why don't we instead call a vote on your initial suggestion lately
> clarified by Matt?
> I got a feeling many are in favor of it.

I believe an unofficial vote on the massive renaming has been happening
separately along with this one.

Cos

> --Konstantin
>
> On Fri, Nov 18, 2011 at 10:20 AM, Arun C Murthy <[EMAIL PROTECTED]> wrote:
> > Nope, just change the version number of releases off this branch.
> >
> > Trunk continues to be trunk. 0.23 or 0.24 etc. etc. whatever we choose to call them come off trunk.
> >
> > This is about one branch only.
> >
> > Arun
> >
> > On Nov 17, 2011, at 7:29 PM, Konstantin Shvachko wrote:
> >
> >> Let me repeat. By renaming ONLY 0.20.security to 1.0
> >> you are replacing Hadoop-trunk with this branch.
> >> Is that the intention of the rename?
> >> Are we switching to the security branch as the new trunk?
> >>
> >> --Konstantin
> >>
> >>
> >>
> >> On Wed, Nov 16, 2011 at 11:48 PM, Eric Yang <[EMAIL PROTECTED]> wrote:
> >>> +1
> >>>
> >>> On Wed, Nov 16, 2011 at 4:49 PM, Owen O'Malley <[EMAIL PROTECTED]> wrote:
> >>>> +1 for release future 2xx releases as 1.x.y.
> >>>>
> >>>> I believe the right mapping is:
> >>>> rename branch-0.20-security to branch-1
> >>>> copy branch-0.20-security-205 to branch-1.0
> >>>>
> >>>> Then the 1.0.x releases will come off of the branch-1.0 and branch-1 will
> >>>> be the upcoming 1.1.x releases.
> >>>>
> >>>> -- Owen
> >>>>
> >>>
> >
> >

On 11/18/11 4:30 PM, "Konstantin Shvachko" <[EMAIL PROTECTED]> wrote:

>Doesn't having trunk on lesser version than a branch make Hadoop
>versioning more confusing?

IMO Trunk is named 'trunk', and has no version
http://svn.apache.org/viewvc/hadoop/common/
Where is 0.24?  nowhere (yet).  There is only trunk and the branches.

The pom files in maven may be confusing, since they claim that the code in
the 'trunk' is 0.24.0-SNAPSHOT.
http://svn.apache.org/viewvc/hadoop/common/trunk/pom.xml?view=markup
One should not have to commit to a branch name before branching from trunk!

Just change the trunk pom project name to trunk-SNAPSHOT.
When a branch occurs, it can be named with a version, and the pom's in the
branch updated appropriately.

This way, trunk's version never changes -- which is helpful after a branch
for many IDE's that derive config from maven.  It also allows consistency
between svn paths and maven versions.
OT: (the maven release plugin is restrictive and flawed IMO.  It conflates
naming with version control, only working well if you follow its default
'rename where you branched from' policy.  Use 'mvn versions:set' and
svn/git instead for branching).

>People were asking for consistent non-confusing versioning schema.
>Why don't we instead call a vote on your initial suggestion lately
>clarified by Matt?
>I got a feeling many are in favor of it.
>
>--Konstantin
>
>On Fri, Nov 18, 2011 at 10:20 AM, Arun C Murthy <[EMAIL PROTECTED]>
>wrote:
>> Nope, just change the version number of releases off this branch.
>>
>> Trunk continues to be trunk. 0.23 or 0.24 etc. etc. whatever we choose
>>to call them come off trunk.
>>
>> This is about one branch only.
>>
>> Arun
>>
>> On Nov 17, 2011, at 7:29 PM, Konstantin Shvachko wrote:
>>
>>> Let me repeat. By renaming ONLY 0.20.security to 1.0
>>> you are replacing Hadoop-trunk with this branch.
>>> Is that the intention of the rename?
>>> Are we switching to the security branch as the new trunk?
>>>
>>> --Konstantin
>>>
>>>
>>>
>>> On Wed, Nov 16, 2011 at 11:48 PM, Eric Yang <[EMAIL PROTECTED]> wrote:
>>>> +1
>>>>
>>>> On Wed, Nov 16, 2011 at 4:49 PM, Owen O'Malley <[EMAIL PROTECTED]>
>>>>wrote:
>>>>> +1 for release future 2xx releases as 1.x.y.
>>>>>
>>>>> I believe the right mapping is:
>>>>> rename branch-0.20-security to branch-1
>>>>> copy branch-0.20-security-205 to branch-1.0
>>>>>
>>>>> Then the 1.0.x releases will come off of the branch-1.0 and branch-1
>>>>>will
>>>>> be the upcoming 1.1.x releases.
>>>>>
>>>>> -- Owen
>>>>>
>>>>
>>
>>

+1 for 0.20.205.1 --> 1.0.0
On Tue, Nov 15, 2011 at 8:22 PM, Arun Murthy <[EMAIL PROTECTED]> wrote:

> Please vote on naming 'future' releases off branch-0.20-security (with
> both security & append) as hadoop-1.x.x.
>
> We should also rename branch-0.20-security as branch-1.x.x.
>
> I propose we use the common 3-part major, minor (compatible, newer
> features) and sub-minor (bug fixes) scheme as suggested by Doug in the
> previous thread.
>
> The vote will run the normal 5 days.
>
> thanks,
> Arun
>

-1 (non-binding)

While I support renaming 0.20.205.1 as 1.0.0 and branch-0.20-security as
branch-1.x.x, I think that renumbering other branches in play (0.22, 0.23,
0.24) should be done in the same transaction. Otherwise, the goal of this
whole exercise (I.e. Reducing user-confusion) will be defeated.

- Milind

---
Milind Bhandarkar
Greenplum Labs, EMC
(Disclaimer: Opinions expressed in this email are those of the author, and
do not necessarily represent the views of any organization, past or
present, the author might be affiliated with.)

On 11/15/11 8:22 PM, "Arun Murthy" <[EMAIL PROTECTED]> wrote:

>Please vote on naming 'future' releases off branch-0.20-security (with
>both security & append) as hadoop-1.x.x.
>
>We should also rename branch-0.20-security as branch-1.x.x.
>
>I propose we use the common 3-part major, minor (compatible, newer
>features) and sub-minor (bug fixes) scheme as suggested by Doug in the
>previous thread.
>
>The vote will run the normal 5 days.
>
>thanks,
>Arun
>

+1. I think this is the best incremental step forward and is in the context of an actual release we are almost ready to vote on.

Cheers,
Nige
On 11/15/11 8:22 PM, "Arun Murthy" <[EMAIL PROTECTED]> wrote:

> Please vote on naming 'future' releases off branch-0.20-security (with
> both security & append) as hadoop-1.x.x.
>
> We should also rename branch-0.20-security as branch-1.x.x.
>
> I propose we use the common 3-part major, minor (compatible, newer
> features) and sub-minor (bug fixes) scheme as suggested by Doug in the
> previous thread.
>
> The vote will run the normal 5 days.
>
> thanks,
> Arun
>