Mailing-List: contact dev-help@continuum.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@continuum.apache.org
Received-SPF: pass (athena.apache.org: domain of oching@exist.com designates
 74.125.44.158 as permitted sender)
Message-ID: <1a57a2980811171638l1d91db38ocba6cd16ae4775bd@mail.gmail.com>
Date: Tue, 18 Nov 2008 08:38:53 +0800
From: "Maria Odea Ching" <oching@apache.org>
Sender: oching@exist.com
To: dev@continuum.apache.org
Subject: Re: [DRAFT] Continuum Release Guidelines
In-Reply-To: <adba96190811141914h6980c63eucdb4bf71ac7fd49f@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_46664_4105895.1226968733509"
References: <adba96190811141914h6980c63eucdb4bf71ac7fd49f@mail.gmail.com>

------=_Part_46664_4105895.1226968733509
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Sounds good to me, so here's my +1 :)
Thanks Wendy!

-Deng

On Sat, Nov 15, 2008 at 11:14 AM, Wendy Smoak <wsmoak@gmail.com> wrote:

> As I'd like to get started on the 1.3 series, I spent some time
> writing down this crazy idea I have about using httpd- or struts-
> style versioning for Continuum.  :)
>
> The goal is to make it simple for release managers by not requiring a
> new release to change the "label", while still communicating clearly
> to users so they know what to expect.
>
> The draft can be edited on the wiki:
>
> http://cwiki.apache.org/confluence/display/CONTINUUM/Continuum+Release+Gu=
idelines
>
> If you have a totally different idea, just add a new section to the
> page.  Here's mine so far:
>
> Continuum Release Guidelines =96 DRAFT
>
>    * Continuum is versioned X.Y.Z =96 Major.Minor.Build. The Major and
> Minor versions are set at the beginning of a series, after which we
> use sequential build numbers starting with .0. For example, 1.3.0,
> 1.3.1, 1.3.2.
>
>    * Ideally each version is tagged and built exactly once. The
> Release Manager (RM) has discretion to re-build a version if something
> goes wrong during the release process, but once a version has been
> made available for public download, that version number may not be
> re-used.
>
>    * During the vote, an additional qualifier is determined. For
> example: 1.3.0 (M1) or 1.3.7 (GA). Respectively, these mean Milestone
> 1 and General Availability. Qualifiers such as Alpha and Beta are also
> acceptable, as is RC (Release Candidate).
>
>    * If the vote does not pass, the qualifier may be reused. For
> example, if 1.3.0 was meant to be M1 but does not get approved, 1.3.1
> can become Milestone 1.
>
>    * When releases are announced to the community, the additional
> qualifier is used in addition to the version number. For example:
> [ANN] Continuum 1.3.3 (Milestone 2) Release or [ANN] Continuum 1.3.6
> (GA) Release
>
>    * A qualifier can be changed by calling a new vote. If we get to
> 1.3.8 (M5) and decide that it has no problems and there's nothing else
> we want to add, we can simply re-label it GA and update the website.
>
>    * New features may be added to 1.3.x releases until we reach GA,
> at which point only minor changes should be made.
>
> --
> Wendy
>

------=_Part_46664_4105895.1226968733509--