You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@buildr.apache.org by Alexis Midon <al...@gmail.com> on 2010/07/24 10:28:27 UTC
Re: release task
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 <al...@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 <al...@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..
>>> ********************************
>>>
>>
>>
>
Re: release task
Posted by Antoine Toulme <an...@lunar-ocean.com>.
We now have a weekly build for the website.
The page is available here:
http://hudson.zones.apache.org/hudson/view/buildr/job/Buildr-website-build/2/artifact/_site/releasing.html
<http://hudson.zones.apache.org/hudson/view/buildr/job/Buildr-website-build/2/artifact/_site/releasing.html>The
style is off and needs to be adjusted. I'll try to proofread it before we
release.
Thanks,
Antoine
On Sat, Jul 24, 2010 at 01:28, Alexis Midon <al...@gmail.com> wrote:
> 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 <al...@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..
> >>> ********************************
> >>>
> >>
> >>
> >
>