You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@buildr.apache.org by Jean-Philippe Caruana <je...@orange-ftgroup.com> on 2010/05/07 12:08:36 UTC
release task
Hi,
I tried to run the release task on my project, but it doesn't work as
*I* would expect.
In our team, we usually don't do any SNAPSHOT version, but several
'release candidate' before going to the integration environnement. This
phase is mandatory since we cannot test everything and we need to check
with cell-phones how our services works.
So, for the next version, let's call it 2.0.0, we will do several -rc
versions : 2.0.0-rc1, 2.0.0-rc2, 2.0.0-rc3 etc... and then the final
2.0.0 version.
I tried to do my 2.0.0-rc1, but buildr war doing 2.0.0 only. (I didn't
really understood how Buildr/core/buildr/with_release_candidate_version
works but split('-') is pretty clear)
How can I do what I want ?
Also, I would like to have interractive dialog when I do a release, for
instance :
"current version is 2.0.0-rc2, what is your new version ?"
Is that possible ?
Thanks
-- 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 Jean-Philippe Caruana <je...@orange-ftgroup.com>.
Le 07/05/2010 17:59, Antoine Toulme a écrit :
> 1. file a bug please
okay : https://issues.apache.org/jira/browse/BUILDR-436
tell me if the patch showing the issue is ok
-- 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>.
Thanks! Yes, we need to make this very specific to your build. Monkey
patching is fine for now, but we will let people implement strategies.
On Mon, May 17, 2010 at 06:28, 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..
> >>> ********************************
> >>>
> >>
> >>
> >
>
Re: release task
Posted by Alexis Midon <al...@gmail.com>.
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 Alexis Midon <al...@gmail.com>.
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 Alexis Midon <al...@gmail.com>.
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 Jean-Philippe Caruana <je...@orange-ftgroup.com>.
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>.
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 (if you look
at Eclipse, it's pretty hard to have that behavior, they have nightly
builds, milestone builds, release builds, and the version is
[N|I|M|R]-v#{timestamp}).
2. We should not split on -, only replace -SNAPSHOT.
I don't think we should jump rc1 to rc2 right away.
On Fri, May 7, 2010 at 13:09, Alexis Midon <al...@gmail.com> wrote:
> Today at the end of a release, you have a jar foo-2.2.0.jar and a new
> version number in the buildfile: 2.2.1-SNAPSHOT
>
> If the last token is not SNAPSHOT, what should be the next version number
> in the buildfile? should buildr try to change the buildfile in that case?
> should buildr be clever and check if the last character is a number and
> increment it, 2.2.0-rc1 -> 2.2.0-rc2 ?
>
>
>
> On Fri, May 7, 2010 at 10:21 AM, Alex Boisvert <al...@gmail.com>wrote:
>
>> ... or ... (yikes!) ... you can monkey-patch the Release class to do
>> exactly
>> what you need for the time being,
>>
>> module Buildr
>> class Release #:nodoc:
>> class << self
>> def with_release_candidate_version
>> # copy & paste existing code and tweak it to match your needs
>> end
>> end
>> end
>> end
>>
>> I agree we should only strip the last token if it matches the -SNAPSHOT
>> expectation.
>>
>> alex
>>
>> On Fri, May 7, 2010 at 8:59 AM, Antoine Toulme <antoine@lunar-ocean.com
>> >wrote:
>>
>> > Hmm...
>> >
>> > 1. file a bug please
>> > 2. use _ or . instead for now. Sorry about that.
>> >
>> > On Fri, May 7, 2010 at 07:58, Jean-Philippe Caruana <
>> > jeanphilippe1.caruana@orange-ftgroup.com> wrote:
>> >
>> > > Le 07/05/2010 16:51, Antoine Toulme a écrit :
>> > >
>> > > I would set the version explicitly in the Buildfile, commit, do
>> buildr
>> > >> release, etc.
>> > >> I might be missing something, I'm not too familiar with RCs in
>> Buildr.
>> > >>
>> > >
>> > > When I commit "2.2.0-rc1" in my buildfile and do a "buildr release",
>> it
>> > > builds a project-artifact-2.2.0.jar. My "-rc1" is dropped (everything
>> > after
>> > > "-" is dropped, in order to drop the "-SNAPSHOT" part)
>> > >
>> > > Sorry this wasn't clear in my previous email.
>> > >
>> > > -- 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 Alexis Midon <al...@gmail.com>.
Today at the end of a release, you have a jar foo-2.2.0.jar and a new
version number in the buildfile: 2.2.1-SNAPSHOT
If the last token is not SNAPSHOT, what should be the next version number in
the buildfile? should buildr try to change the buildfile in that case?
should buildr be clever and check if the last character is a number and
increment it, 2.2.0-rc1 -> 2.2.0-rc2 ?
On Fri, May 7, 2010 at 10:21 AM, Alex Boisvert <al...@gmail.com>wrote:
> ... or ... (yikes!) ... you can monkey-patch the Release class to do
> exactly
> what you need for the time being,
>
> module Buildr
> class Release #:nodoc:
> class << self
> def with_release_candidate_version
> # copy & paste existing code and tweak it to match your needs
> end
> end
> end
> end
>
> I agree we should only strip the last token if it matches the -SNAPSHOT
> expectation.
>
> alex
>
> On Fri, May 7, 2010 at 8:59 AM, Antoine Toulme <antoine@lunar-ocean.com
> >wrote:
>
> > Hmm...
> >
> > 1. file a bug please
> > 2. use _ or . instead for now. Sorry about that.
> >
> > On Fri, May 7, 2010 at 07:58, Jean-Philippe Caruana <
> > jeanphilippe1.caruana@orange-ftgroup.com> wrote:
> >
> > > Le 07/05/2010 16:51, Antoine Toulme a écrit :
> > >
> > > I would set the version explicitly in the Buildfile, commit, do buildr
> > >> release, etc.
> > >> I might be missing something, I'm not too familiar with RCs in Buildr.
> > >>
> > >
> > > When I commit "2.2.0-rc1" in my buildfile and do a "buildr release", it
> > > builds a project-artifact-2.2.0.jar. My "-rc1" is dropped (everything
> > after
> > > "-" is dropped, in order to drop the "-SNAPSHOT" part)
> > >
> > > Sorry this wasn't clear in my previous email.
> > >
> > > -- 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 Alex Boisvert <al...@gmail.com>.
... or ... (yikes!) ... you can monkey-patch the Release class to do exactly
what you need for the time being,
module Buildr
class Release #:nodoc:
class << self
def with_release_candidate_version
# copy & paste existing code and tweak it to match your needs
end
end
end
end
I agree we should only strip the last token if it matches the -SNAPSHOT
expectation.
alex
On Fri, May 7, 2010 at 8:59 AM, Antoine Toulme <an...@lunar-ocean.com>wrote:
> Hmm...
>
> 1. file a bug please
> 2. use _ or . instead for now. Sorry about that.
>
> On Fri, May 7, 2010 at 07:58, Jean-Philippe Caruana <
> jeanphilippe1.caruana@orange-ftgroup.com> wrote:
>
> > Le 07/05/2010 16:51, Antoine Toulme a écrit :
> >
> > I would set the version explicitly in the Buildfile, commit, do buildr
> >> release, etc.
> >> I might be missing something, I'm not too familiar with RCs in Buildr.
> >>
> >
> > When I commit "2.2.0-rc1" in my buildfile and do a "buildr release", it
> > builds a project-artifact-2.2.0.jar. My "-rc1" is dropped (everything
> after
> > "-" is dropped, in order to drop the "-SNAPSHOT" part)
> >
> > Sorry this wasn't clear in my previous email.
> >
> > -- 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>.
Hmm...
1. file a bug please
2. use _ or . instead for now. Sorry about that.
On Fri, May 7, 2010 at 07:58, Jean-Philippe Caruana <
jeanphilippe1.caruana@orange-ftgroup.com> wrote:
> Le 07/05/2010 16:51, Antoine Toulme a écrit :
>
> I would set the version explicitly in the Buildfile, commit, do buildr
>> release, etc.
>> I might be missing something, I'm not too familiar with RCs in Buildr.
>>
>
> When I commit "2.2.0-rc1" in my buildfile and do a "buildr release", it
> builds a project-artifact-2.2.0.jar. My "-rc1" is dropped (everything after
> "-" is dropped, in order to drop the "-SNAPSHOT" part)
>
> Sorry this wasn't clear in my previous email.
>
> -- 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 Jean-Philippe Caruana <je...@orange-ftgroup.com>.
Le 07/05/2010 16:51, Antoine Toulme a écrit :
> I would set the version explicitly in the Buildfile, commit, do buildr
> release, etc.
> I might be missing something, I'm not too familiar with RCs in Buildr.
When I commit "2.2.0-rc1" in my buildfile and do a "buildr release", it
builds a project-artifact-2.2.0.jar. My "-rc1" is dropped (everything
after "-" is dropped, in order to drop the "-SNAPSHOT" part)
Sorry this wasn't clear in my previous email.
-- 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>.
I would set the version explicitly in the Buildfile, commit, do buildr
release, etc.
I might be missing something, I'm not too familiar with RCs in Buildr.
On Fri, May 7, 2010 at 03:11, Jean-Philippe Caruana <
jeanphilippe1.caruana@orange-ftgroup.com> wrote:
> Le 07/05/2010 12:08, jeanphilippe1.caruana@orange-ftgroup.com a écrit :
>
> So, for the next version, let's call it 2.0.0, we will do several -rc
>> versions : 2.0.0-rc1, 2.0.0-rc2, 2.0.0-rc3 etc... and then the final
>> 2.0.0 version.
>>
>
> To be more precise, rc version go to integration environment and we need it
> to be put in our public maven repo. Then, we do the production version (goes
> to acceptance then prod environments)
>
> --
> Jean-Philippe Caruana - jeanphilippe.caruana@orange-ftgroup.com
> Tel : 01 53 90 85 33 / 1533 - Projet AVSP
>
> ********************************
> 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 Jean-Philippe Caruana <je...@orange-ftgroup.com>.
Le 07/05/2010 12:08, jeanphilippe1.caruana@orange-ftgroup.com a écrit :
> So, for the next version, let's call it 2.0.0, we will do several -rc
> versions : 2.0.0-rc1, 2.0.0-rc2, 2.0.0-rc3 etc... and then the final
> 2.0.0 version.
To be more precise, rc version go to integration environment and we need
it to be put in our public maven repo. Then, we do the production
version (goes to acceptance then prod environments)
--
Jean-Philippe Caruana - jeanphilippe.caruana@orange-ftgroup.com
Tel : 01 53 90 85 33 / 1533 - Projet AVSP
********************************
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..
********************************