---
layout: default
title: Releasing 
---

Now that we built and test awesome software, let's the world know and release it.


Each buildile 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 contains '-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
Release.next_version = lambda do |this_version| # 1.0.0-SNAPSHOT
    new_version = this_version.split(/\./)
    new_version[0] = new_version[0] + 1
    new_version
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 would generate the buildfile below:
{% 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 %}

{% 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.


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'.