[
https://issues.apache.org/jira/browse/BUILDR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869219#action_12869219
]
Antoine Toulme commented on BUILDR-438:
---------------------------------------
OK with me. I'm a picky guy, but I like also having version numbers that are
explicitely NOT incremented.
For example, in one of my builds, I'm just taking jetty, removing stuff, and
uploading the result. This is the kind of one off job that you would not need
to script unless you wanted to keep track of what you've done.
So I would say: if -SNAPSHOT is here, increment, otherwise, apply blindly the
VERSION_NUMBER. If you like, we can do a warning explaining it's not best
practice. But I would rather not break existing functionality. Otherwise we're
good to go!
> 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.1
>
>
> 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.
