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 eric818@gmail.com designates
 209.85.213.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CA+z3+9Fs1CHRwPPt0m89n30o1tMtnbp_2ro4VuxxyExj3g=QGw@mail.gmail.com>
References: <CAE9339F.5FB11%scott@richrelevance.com>
	<4EC4159B.4040708@apache.org>
	<CA+z3+9Fs1CHRwPPt0m89n30o1tMtnbp_2ro4VuxxyExj3g=QGw@mail.gmail.com>
Date: Wed, 16 Nov 2011 16:05:34 -0800
Message-ID: 
 <CADfbTpE5mX4MxxP9ZajM0Ty3PffJLxGdwhR15OjL-K=syuyuyQ@mail.gmail.com>
Subject: Re: [DISCUSS] Apache Hadoop 1.0?
From: Eric Yang <eric818@gmail.com>
To: general@hadoop.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1 on Matt's proposal.

On Wed, Nov 16, 2011 at 1:11 PM, Matt Foley <mfoley@hortonworks.com> wrote:
> I support giving all three active code branches a clean start, on an equa=
l
> footing:
>
> - The next release of 0.20-security (formerly expected as "0.20.205.1") t=
o
> be 1.0.0, establishing branch-1.0
> - The next release of 0.22 to be 2.0.0, establishing branch-2.0
> - The recent release of 0.23.0 to be 3.0.0, establishing branch-3.0,
> =A0 =A0from which the formerly expected "0.23.1" may be released as 3.0.1
> - All three code branches to obey the established major.minor.patch
> versioning rules going forward.
> - So the next release from trunk to be 3.1.0 or 4.0.0, at the choice of t=
he
> then release manager, and the pleasure of the community.
>
> Regards,
> --Matt
>
> On Wed, Nov 16, 2011 at 11:57 AM, Doug Cutting <cutting@apache.org> wrote=
:
>
>> On 11/16/2011 10:15 AM, Scott Carey wrote:
>> > IMO what is important from the development and maintenance perspective=
 is
>> > the _meaning_ of the
>> > major.minor.patch numbers as described in my previous message.
>> >
>> > If a minor version number bump means that it is a superset of the
>> previous
>> > release and is backwards compatible, then that requirement on its own
>> > answers whether 0.22 can become 1.1, or if it must be a 2.0 release.
>> >
>> > Whether hadoop starts using a new meaning for major.minor.patch is wha=
t
>> is
>> > of interest to me; starting at 1.x.y or 20.x.y or 999.x.y is marketing=
.
>>
>> Scott, this is a great point. =A0Thanks for making it.
>>
>> > The version number is completely meaningless on its own, pure marketin=
g.
>> > However, if the numbers gain meaning through a clear definition of wha=
t
>> > the major.minor.patch numbers signify, then there is meaning and
>> structure
>> > going forward.
>> > The current state of affairs seems to be:
>> > major: =A0always 0
>> > minor: =A0potentially big changes; almost always breaks wire compatibi=
lity;
>> > occasionally breaks API backwards compatibility
>> > minor: =A0typically bug fixes only; 'bug fix' not well defined; almost
>> never
>> > breaks API or wire compatibility
>>
>> Long ago I proposed such rules for Hadoop releases at:
>>
>> http://wiki.apache.org/hadoop/Roadmap
>>
>> These state that pre-1.0 releases behave roughly as above.
>>
>> > I think the community can decide two things independently:
>> >
>> > - Should 0.20.20x be renamed 1.0.y ? =A0(perhaps not, perhaps 0.23 sho=
uld
>> be
>> > 1.0 and the others left alone).
>> > - Should hadoop adopt a new clear definition of major.minor.patch numb=
er
>> > significance?
>>
>> Would you care to call a vote on one or both of these?
>>
>> > example proposal:
>> > * major version number increment: signifies breaks in API backwards
>> > compatibility and/or major architecture overhauls.
>> > * minor version number increment: signifies possible API changes, but
>> > maintains API backwards compatibility. =A0Wire compatibility may break=
 (see
>> > release notes). =A0Included functionality is a superset of previous mi=
nor
>> > release.
>> > * patch version number increment: signifies a release where all
>> > improvements are fully backwards compatible with the previous patch
>> > version, including wire format.
>>
>> This is also similar to what the Roadmap wiki page indicates for
>> post-1.0 releases.
>>
>> Renaming things after the fact to try to make them consistent when the
>> prior rules weren't consistently followed is not easy. =A0Instead we mig=
ht
>> better focus on rules that we intend to obey for releases going forward
>> and then obey them.
>>
>> > Whatever the meaning of the numbers turns out to be will dictate wheth=
er
>> > releases after a 1.0.x need to be 2.0.x or can be 1.1.x
>>
>> Good point. =A0The most accurate approach would probably be to call each
>> existing branch a distinct major release. =A0Dropping the leading zero
>> would reduce confusion and avoid marketing but would still combine
>> 0.20.x and 0.20.20x which perhaps ought to be considered separate major
>> releases. =A0For me this is however a reasonable tradeoff since we're
>> better off focusing on improving things in the future than arguing about
>> marketing and how to hide our past versioning mistakes.
>>
>> Doug
>>
>