[
https://issues.apache.org/jira/browse/BUILDR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889220#action_12889220
]
Alexis Midon commented on BUILDR-438:
-------------------------------------
By the way the behavior implemented by this patch is describe in a new page for
the website.
I pasted here as well for conveniency.
---
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'.
> Release Task: customizable version numbers
> ------------------------------------------
>
> Key: BUILDR-438
> URL: https://issues.apache.org/jira/browse/BUILDR-438
> Project: Buildr
> Issue Type: New Feature
> Components: Core features
> Reporter: Alexis Midon
> Fix For: 1.4.2
>
> Attachments: buildr-438.patch.txt
>
>
> Base on this conversation, http://markmail.org/thread/t7pd773y4m6ncfyd it
> seems that the way Buildr handles versions can be improved.
> 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. The VERSION_NUMBER is then updated with the
> new-version, and the buildfile is committed.
> 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
> }
> The output of Release#bump_version is then used to update VERSION_NUMBER. And
> the buildfile is committed.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
