buildr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antoine Toulme (JIRA)" <j...@apache.org>
Subject [jira] Commented: (BUILDR-438) Release Task: customizable version numbers
Date Wed, 19 May 2010 17:36:54 GMT

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


Mime
View raw message