blob: c7cab0f6e69e58d3a7abf3f595870f33ad51e84b [file] [log] [blame]
---
layout: default
title: Releasing
---
Now that we built and tested our awesome software, let's tell the world and release it.
Each buildfile can specify the current version with a constant named @VERSION_NUMBER@ or @THIS_VERSION@.
{% highlight ruby %}
THIS_VERSION = "1.0.0-SNAPSHOT"
define 'killer-app' do
project.version = THIS_VERSION
# ...
end
{% endhighlight %}
h2(#default). What does a release do?
The default behavior of the @Release@ task is the following:
# Check that the version to be released and the next version are different
# Check that the project is being tracked by Git or Subversion
# Package, test and deploy the artifacts using @THIS_VERSION@ value minus the @-SNAPSHOT@ suffix (if any)
# 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@ ends with @-SNAPSHOT@.
So, at the end of a release, the buildfile now looks like this:
{% highlight ruby %}
THIS_VERSION = "1.0.1-SNAPSHOT"
define 'killer-app' do
project.version = THIS_VERSION
# ...
end
{% endhighlight %}
And the Git repository now contains two new commits and a new tag.
{% highlight sh %}
~/w/killer-app[master]$git ol -4
c1af3d5 (HEAD, origin/master, master) Changed version number to 1.0.1-SNAPSHOT
dd35015 (tag: 1.0.0) Changed version number to 1.0.0
76c96e7 Last fix before the release
{% endhighlight %}
h2(#custom_version). How to specify my own version number scheme?
If @THIS_VERSION@ does not contain @-SNAPSHOT@, Buildr delegates the resolution of the next version number to the user which has 2 differents ways to express her wishes: @Release.next_version@ or the environment variable @NEXT_VERSION@.
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.
{% highlight ruby %}
THIS_VERSION = "1.0.0-SNAPSHOT"
# a string
Release.next_version = "2.0.0-SNAPSHOT"
# or a proc - equivalent result
Release.next_version = lambda do |this_version| # 2.0.0-SNAPSHOT
new_version = THIS_VERSION.split /\./
new_version[0] = new_version[0].to_i + 1
new_version[1] = 0
new_version[2] = '0-SNAPSHOT'
new_version.join '.'
end
define 'killer-app' do
project.version = THIS_VERSION
# ...
end
{% endhighlight %}
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.
For conveniency, this variable is case insensitive.
So, all 3 following commands will run a release with a custom new version:
{% highlight sh %}
$ buildr release next_version="1.0.0-rc1"
$ env next_version="1.0.0-rc1" buildr release
$ 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"
define 'killer-app' do
project.version = THIS_VERSION
# ...
end
{% endhighlight %}
The environment variable @NEXT_VERSION@ has precedence over Release.next_version.
h3(#alternate_version_file). Using an alternate version file
To avoid dealing with conflicts over the Buildfile, you can store the version inside version.rb next to it.
version.rb:
{% highlight ruby %}
THIS_VERSION = "1.0.0-rc1"
{% endhighlight %}
Your Buildfile should import version.rb like so:
{% highlight ruby %}
require File.join(File.dirname(__FILE__), 'version.rb')
{% endhighlight %}
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 @THIS_VERSION@ without @-SNAPSHOT@.