[
https://issues.apache.org/jira/browse/BUILDR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antoine Toulme resolved BUILDR-438.
-----------------------------------
Assignee: Antoine Toulme
Resolution: Fixed
Merged with trunk and committed:
00:09:09~/w/buildr>svn ci CHANGELOG spec/core/build_spec.rb
doc/releasing.textile doc/_layouts/default.html lib/buildr/core/build.rb -m
"fix for BUILDR-438, thanks to Alexis Midon"
Sending CHANGELOG
Sending doc/_layouts/default.html
Adding doc/releasing.textile
Sending lib/buildr/core/build.rb
Sending spec/core/build_spec.rb
Transmitting file data .....
Committed revision 966111.
> 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
> Assignee: Antoine Toulme
> 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.