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