[
https://issues.apache.org/jira/browse/BUILDR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869036#action_12869036
]
Jean-Philippe Caruana commented on BUILDR-438:
----------------------------------------------
I think the template is a great idea but I prefer the the idea of the version
in the command line.
To me, a command line prompt would be a great option.
$ buildr release --prompt-version
> Current version is X.Y.Z. What is the new version number ? [X.Y+1.Z] #
> asks with a default pattern based on Alexis' idea)
It's very important to me because, as I said in this discussion before, the
version name is a *decision* made by either the team, the product owner, or
anything related to commercial politics. There will never be an automatic way
of doing it.
Also, I don't think editing the buildfile (and comitting it) for doing this is
the best idea. This makes the release task a 3 step one
- edit buildfile
- commit it
- buildr release
I think 1 step is shorter and less error prone
- buildr release --prompt-version
the "--prompt-version" could be on option in the build.yaml file for instance.
What do you think ?
> 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.
> 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
> }
> 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.
