I created I issue for this discussion:
https://issues.apache.org/jira/browse/BUILDR-438
On Tue, May 18, 2010 at 10:05 AM, Alexis Midon <alexismi...@gmail.com>wrote:
> 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='1.0.0-rc1-SNAPSHOT'
> Release.bump_version = 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.caru...@orange-ftgroup.com> wrote:
>
>> Hi,
>>
>> Le 07/05/2010 22:15, Antoine Toulme a écrit :
>>
>> 1. I think we should encourage people to have their own policy for
>>> version
>>> 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 it will be x.y.z : buildr can't know the client validited it in
>> his environment 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
>> Business 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 shall
>> 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..
>> ********************************
>>
>
>
