buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexis Midon <alexismi...@gmail.com>
Subject Re: release task
Date Sat, 24 Jul 2010 08:28:27 GMT
BUILDR-438 has been flag as resolved, even though the documentation needs
some proof-reading and improvement. The Releasing page was really a first
shot, late in the evening.

On Tue, May 18, 2010 at 7:08 PM, Alexis Midon <alexismidon@gmail.com> wrote:

> 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 <alexismidon@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.caruana@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..
>>> ********************************
>>>
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message