Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@hadoop.apache.org
Received-SPF: pass (nike.apache.org: domain of scott@richrelevance.com
 designates 64.78.17.19 as permitted sender)
From: Scott Carey <scott@richrelevance.com>
To: "general@hadoop.apache.org" <general@hadoop.apache.org>
Date: Tue, 15 Nov 2011 23:06:35 -0800
Subject: Re: [DISCUSS] Apache Hadoop 1.0?
Thread-Topic: [DISCUSS] Apache Hadoop 1.0?
Thread-Index: AcykLfGfuP4lrnhlR7mWIww2FVPHcA==
Message-ID: <CAE89F57.5FA4D%scott@richrelevance.com>
In-Reply-To: <20111116024752.GB8696@linspire.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.13.0.110805
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 11/15/11 6:47 PM, "Konstantin Boudnik" <cos@apache.org> wrote:

>And once again - 0.22 seems to be forgotten for an unexplained reason.
>
>I urge to stick to original Arun's proposal and use 0.22 as 2.0
>With the correction I like the following proposal.

If 0.20.20x ends up in the 1.0.x line, then 0.22.x should end up in the
1.1.x line, IMO.

0.22 is not a radical incompatible overhaul from 0.20.20x.  So IMO it
should not change the major version number, but only the minor one.

However, 0.23 IS a major change, and could justify a 2.0.x.

This all assumes the version numbers are going to start meaning something
along the lines of

major.minor.patch

where=20
- changes to major denote big, incompatible changes,
- changes to minor denote large changes/additions/improvements, but
backwards compatible
- changes to patch denote bugfixes or minor additions/improvements with no
compatibility impact.

-Scott


>
>Cos
>
>On Tue, Nov 15, 2011 at 06:42PM, Matt Foley wrote:
>> I agree with some prior posters that renaming the 0.20-security
>>sustaining
>> branch could be confusing.
>> How about the following (pseudo-code)?
>>=20
>> ## Just before we are ready to make rc0 for release 0.20.205.1, do:
>> svn copy branch-0.20-security-205 branch-1.0
>> ## and actually release it from branch-1.0 as release 1.0.0
>>=20
>> ## Then, after the 1.0.0 release vote ends successfully, do:
>> svn copy branch-0.20-security branch-1.1
>> ## This will pick up the remaining changes done to date, which would
>> ## have gone into 0.20.206.0, and will instead go into release 1.1.0,
>> ## sometime in the future
>>=20
>> ## However, since branch-0.23 was just recently split from trunk, it
>>should
>> be
>> ## upgraded to 2.0 in the usual way, with a rename:
>> svn mv branch-0.23 branch-2.0
>> ## and also rename the actual release:
>> svn mv tags/release-0.23.0 tags/release-2.0.0
>> ## The work currently going into the future 0.23.1 will become 2.0.1,
>>not
>> 2.1.0.
>> ## Work going into trunk will become 2.1 or higher in the future.
>>=20
>> This is a concrete, actionable proposal.  In an effort to establish
>> consensus, would it be appropriate to call a vote on it?
>> --Matt
>>=20
>>=20
>> On Tue, Nov 15, 2011 at 5:56 PM, Doug Cutting <cutting@apache.org>
>>wrote:
>>=20
>> > On 11/15/2011 05:49 PM, Eli Collins wrote:
>> > > Are you suggesting a two part version scheme?  Ie
>> > >
>> > > 0.23.0 -> 2.0
>> > > 0.23.1 -> 2.1
>> >
>> > I didn't specify.  We could either do that or:
>> >
>> >  0.23.0 -> 2.0.0
>> >  0.23.1 -> 2.0.1
>> >    ...
>> >  0.24.0 -> 2.1.0
>> >    ...
>> >
>> > I don't care which much.  Do you?
>> >
>> > > fwiw I'd map 0.20.200.0 to 1.0,  203.0 would be 1.3, 205.0, would be
>> > > 1.5. I wouldn't rename 21 since we've abandoned it. I wouldn't
>>rename
>> > > 22 either since it both has features that are in 20x, and 20x has
>> > > features not in 22, and is not yet released or stable. Seems hard to
>> > > come up with a reasonable version number for it.
>> >
>> > This is about the fourth or fifth different proposal around these.
>>I'm
>> > not sure things are congealing around a consensus.  I don't want to
>> > stand in the way of that, but I think we might first settle the part
>> > that we're nearer consensus on.
>> >
>> > Doug
>> >