Author: boisvert
Date: Thu Sep 23 22:33:13 2010
New Revision: 1000654
URL: http://svn.apache.org/viewvc?rev=1000654&view=rev
Log:
Cosmetic updates to releasing.textile
Modified:
buildr/trunk/doc/releasing.textile
Modified: buildr/trunk/doc/releasing.textile
URL:
http://svn.apache.org/viewvc/buildr/trunk/doc/releasing.textile?rev=1000654&r1=1000653&r2=1000654&view=diff
==============================================================================
--- buildr/trunk/doc/releasing.textile (original)
+++ buildr/trunk/doc/releasing.textile Thu Sep 23 22:33:13 2010
@@ -1,6 +1,6 @@
---
layout: default
-title: Releasing
+title: Releasing
---
Now that we built and test awesome software, let's the world know and release
it.
@@ -29,7 +29,7 @@ The default behavior of the Release task
# Tag the repository with the released version number
# Update the value of THIS_VERSION in the buildfile with the next version
number
-Buildr will increment the last digit of the 3-digit versioni number if
THIS_VERSION contains '-SNAPSHOT'.
+Buildr will increment the last digit of the 3-digit versioni number if
THIS_VERSION contains '-SNAPSHOT'.
So, at the end of a release, the buildfile now looks like this:
{% highlight ruby %}
@@ -59,7 +59,7 @@ If THIS_VERSION does not contain '-SNAPS
h3(#next_version_proc). Using Release.next_version
-The Release class can receive the next version of the buildfile. This could be
a string or a proc that would receive the current version and return the next
version.
+The @Release@ class can receive the next version of the buildfile. This could
be a string or a proc that would receive the current version and return the
next version.
{% highlight ruby %}
THIS_VERSION = "1.0.0-SNAPSHOT"
@@ -85,11 +85,11 @@ end
h3(#next_version_envvar). Using the environment variable NEXT_VERSION
-If the environment variable NEXT_VERSION is set, Buildr will use this value to
update THIS_VERSION at the end of the release.
+If the environment variable @NEXT_VERSION@ is set, Buildr will use this value
to update @THIS_VERSION@ at the end of the release.
For conveniency, this variable is case insensitive.
-So, all 3 following commands will run a release with a custom new version:
+So, all 3 following commands will run a release with a custom new version:
{% highlight sh %}
$ buildr release next_version="1.0.0-rc1"
@@ -97,8 +97,8 @@ $ env next_version="1.0.0-rc1" buildr re
$ env NEXT_VERSION="1.0.0-rc1" buildr release
{% endhighlight %}
-
Those commands will generate the Buildfile below:
+
{% highlight ruby %}
THIS_VERSION = "1.0.0-rc1"
@@ -110,10 +110,9 @@ define 'killer-app' do
end
{% endhighlight %}
-The environment variable NEXT_VERSION has precedence over Release.next_version.
-
+The environment variable @NEXT_VERSION@ has precedence over
Release.next_version.
h2(#custom_tag_and_msg). How to specify my own tag name and commit message?
-As explained earlier, Buildr will create two new commits and a new tag in the
version control system. Similarly to Release.next_version, the commit message
and the tag name can be customized with Release.message and Release.tag_name.
Both could be strings or procs that would receive the released version i.i
THIS_VERSION without '-SNAPSHOT'.
+As explained earlier, Buildr will create two new commits and a new tag in the
version control system. Similarly to @Release.next_version@, the commit message
and the tag name can be customized with @Release.message@ and
@release.tag_n...@. Both could be strings or procs that would receive the
released version @THIS_VERSION@ without @-snaps...@.