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 <alexismi...@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 <alexismi...@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 <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.. > >>> ******************************** > >>> > >> > >> > > >
