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 emmanuel.venisse@gmail.com
 designates 66.249.92.170 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=jueZgrmThd+iqypeWZWjnaqfOKsNlLilHv4CC1J1DFPn00ASTvPH91Y1D3VTNo0p6b
         VkGupAlGN1IYo4jgiQKmemSChkwX/atgRsvankzOqvrjFUUKNkj8pEUQRtybzMi/F3wb
         p+V+RZZ3+L1phIdC5M/oOXElDxWP5MzByifcw=
Message-ID: <f345f3480811170848n44af5289h408e708304a948f5@mail.gmail.com>
Date: Mon, 17 Nov 2008 17:48:51 +0100
From: "Emmanuel Venisse" <emmanuel.venisse@gmail.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_39602_8011261.1226940531781"
References: <adba96190811141914h6980c63eucdb4bf71ac7fd49f@mail.gmail.com>

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

+1

Emmanuel

On Sat, Nov 15, 2008 at 4: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_39602_8011261.1226940531781--