Mailing-List: contact users-help@buildr.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@buildr.apache.org
Received-SPF: pass (nike.apache.org: domain of alexismidon@gmail.com
 designates 209.85.212.44 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=B5KAeWKExQDGGyWtEkdPEDw96JScBqw471YdvQOkOoY8doaol+TtKBSxLQAf4SES1B
         D2K4Qg6ZD6wBdnw9Umw2fKWdtg8Jafq4SPO7VZxd9+KhdcC+4JSgXDPvxdx/dprTGjF4
         7wHK0Vd29z82Pb6oCKV1abdz5W/umELs/cymc=
MIME-Version: 1.0
In-Reply-To: <4BF14492.1070402@orange-ftgroup.com>
References: <4BE3E6A4.9070303@orange-ftgroup.com>
 <4BE3E73B.2010702@orange-ftgroup.com>
	<o2hf97124911005070751s4a857cd7k2b46aacd048723e@mail.gmail.com>
	<4BE42AAB.7030608@orange-ftgroup.com>
 <q2sf97124911005070859kfbd83fd9g26daaecfd30cfe4c@mail.gmail.com>
	<t2u4dcd15a91005071021ra7b81b7drb8e9fac26506eee1@mail.gmail.com>
	<n2m4c1d6a901005071309h7f8828b5h79cef16456eaebaf@mail.gmail.com>
	<t2wf97124911005071315l484298cj7a335b9d914cbe69@mail.gmail.com>
	<4BF14492.1070402@orange-ftgroup.com>
From: Alexis Midon <alexismidon@gmail.com>
Date: Tue, 18 May 2010 10:05:19 -0700
Message-ID: <AANLkTilWym48DTWQcs5NZ4NWIeOUu7iHB-LPRAYlQoDl@mail.gmail.com>
Subject: Re: release task
To: users@buildr.apache.org, jeanphilippe1.caruana@orange-ftgroup.com
Content-Type: multipart/alternative; boundary=0016e68f9ca7cd08290486e15929

--0016e68f9ca7cd08290486e15929
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I've been thinking about this release issue and I'm not sure that using the
prompt will help a lot.
Here is what I suggest:

# default behavior
The default supported version scheme is the 3-digit number. Buildr releases
VERSION_NUMBER minus -SNAPSHOT, and increments the last digit of that
version to get the new version.
1.0.0 -> 1.0.1
If the VERSION_NUMBER does not match this pattern, then the release should
fail.
We could relax this convention to check if the last char is a digit and if
so increment it.

# custom increment
If the default behavior does fit one's needs, the method
Release.bump_version receives a block that lets the user implement his
custom strategy. This will be consistent with Release#tag_name, and
#commit_message.

A buildfile could look like this:
VERSION_NUMBER=3D'1.0.0-rc1-SNAPSHOT'
Release.bump_version =3D lambda {  |version|  # the version number without =
the
-SNAPSHOT suffix, i.e. 1.0.0-rc1
    version[0..-2]+(version[-1].to_i+1).to_s   # returns 1.0.0-rc2
}

When the version template changes - let's say you're done with the release
candidates - you will manually edit the buildfile and change the version
number to 1.0.0-SNAPSHOT. Then commit the buildfile.

What you guys think?


On Mon, May 17, 2010 at 6:28 AM, Jean-Philippe Caruana <
jeanphilippe1.caruana@orange-ftgroup.com> wrote:

> Hi,
>
> Le 07/05/2010 22:15, Antoine Toulme a =C3=A9crit :
>
>  1. I think we should encourage people to have their own policy for versi=
on
>> naming. Most of the time using the incremental approach is fine, but for
>> releasing, they may want to pass a promoting version fragment
>>
>
>  2. We should not split on -, only replace -SNAPSHOT.
>>
>
> Okay, I'll file a bug report for this one.
>
>
>  I don't think we should jump rc1 to rc2 right away.
>>
>
> I think buildr should ask the next version : it doesn't have to (and can'=
t)
> guess the next release name. Sometines, it will be x.y.z-rc2, sometimes i=
t
> will be x.y.z : buildr can't know the client validited it in his environm=
ent
> and that we decided to make a final release "production ready".
>
>
> -- Jean-Philippe Caruana
> ********************************
> Ce message et toutes les pieces jointes (ci-apres le "message") sont
> confidentiels et etablis a l'attention exclusive de ses destinataires.
> Toute utilisation ou diffusion non autorisee est interdite.
> Tout message electronique est susceptible d'alteration. Multimedia Busine=
ss
> Services decline
> toute responsabilite au titre de ce message s'il a ete altere, deforme
> ou falsifie.
> Si vous n'etes pas destinataire de ce message, merci de le detruire
> immediatement et d'avertir l'expediteur.
> *********************************
> This message and any attachments (the "message") are confidential and
> intended solely for the addressees. Any unauthorised use or
> dissemination is prohibited.
> Messages are susceptible to alteration. Multimedia Business Services shal=
l
> not be liable for the
> message if altered, changed or falsified.
> If you are not the intended addressee of this message, please cancel it
> immediately and inform the sender..
> ********************************
>

--0016e68f9ca7cd08290486e15929--