Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
MapReduce, mail # dev - Release numbering for branch-2 releases


Copy link to this message
-
Re: Release numbering for branch-2 releases
Suresh Srinivas 2013-02-04, 22:14
On Mon, Feb 4, 2013 at 1:07 PM, Owen O'Malley <[EMAIL PROTECTED]> wrote:

> I think that using "-(alpha,beta)" tags on the release versions is a really
> bad idea.
Why? Can you please share some reasons?

I actually think alpha and beta and stable/GA are much better way to set
the expectation
of the quality of a release. This has been practiced in software release
cycle for a long time.
Having an option to release alpha is good for releasing early and getting
feedback from
people who can try it out and at the same time warning other not so
adventurous users on
quality expectation.

Or do you propose any release that is not marked stable (currently 1.x) is
implicitly alpha/beta?

All releases should follow the strictly numeric
> (Major.Minor.Patch) pattern that we've used for all of the releases except
> the 2.0.x ones.
>
> -- Owen
>
>
> On Mon, Feb 4, 2013 at 11:53 AM, Stack <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Feb 4, 2013 at 10:46 AM, Arun C Murthy <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Would it better to have 2.0.3-alpha, 2.0.4-beta and then make 2.1 as a
> > > stable release? This way we just have one series (2.0.x) which is not
> > > suitable for general consumption.
> > >
> > >
> >
> > That contains the versioning damage to the 2.0.x set.  This is an
> > improvement over the original proposal where we let the versioning mayhem
> > run out 2.3.
> >
> > Thanks Arun,
> > St.Ack
> >
>

--
http://hortonworks.com/download/