You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@buildr.apache.org by "Alexis Midon (JIRA)" <ji...@apache.org> on 2010/05/18 19:08:44 UTC
[jira] Created: (BUILDR-438) Release Task: customizable version
numbers
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.
[jira] Commented: (BUILDR-438) Release Task: customizable version
numbers
Posted by "Alexis Midon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869248#action_12869248 ]
Alexis Midon commented on BUILDR-438:
-------------------------------------
I'm not sure I understand your case. It seems you just want to package and upload, right? That's exactly what the release does, plus some version massaging and VCS magic.
So if you don't need the later, you could just do 'buildr clean upload'
but maybe I'm missing your point.
> 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.
[jira] Updated: (BUILDR-438) Release Task: customizable version
numbers
Posted by "Antoine Toulme (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Antoine Toulme updated BUILDR-438:
----------------------------------
Fix Version/s: 1.4.2
(was: 1.4.1)
> 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
>
>
> 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.
[jira] Commented: (BUILDR-438) Release Task: customizable version
numbers
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890604#action_12890604 ]
Hudson commented on BUILDR-438:
-------------------------------
Integrated in Buildr-ci-build #82 (See [http://hudson.zones.apache.org/hudson/job/Buildr-ci-build/82/])
fix for BUILDR-438, thanks to Alexis Midon
> 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.
[jira] Commented: (BUILDR-438) Release Task: customizable version
numbers
Posted by "Antoine Toulme (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869356#action_12869356 ]
Antoine Toulme commented on BUILDR-438:
---------------------------------------
I also wanted to create a tag. But now that you mention it, I indeed could not release because it was a git subfolder.
However my point still applies. You don't want to change the way it works now by failing if there's no -SNAPSHOT.
In other words remove the line below from the bug description:
If the VERSION_NUMBER does not match this pattern, then the release should fail.
> 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.
[jira] Commented: (BUILDR-438) Release Task: customizable version
numbers
Posted by "Alexis Midon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869187#action_12869187 ]
Alexis Midon commented on BUILDR-438:
-------------------------------------
You get the "interactive" part with Antoine's solution, the env variable set in the command line and reused in the lambda.
So I think the lambda meets everyone's needs with less fat.
> 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.
[jira] Updated: (BUILDR-438) Release Task: customizable version
numbers
Posted by "Alexis Midon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexis Midon updated BUILDR-438:
--------------------------------
Attachment: buildr-438.patch.txt
Here is a patch for this improvement.
The same patch is also available at http://github.com/alexism/buildr/tree/BUILDR-438
> 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.
[jira] Commented: (BUILDR-438) Release Task: customizable version
numbers
Posted by "Alexis Midon (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (BUILDR-438) Release Task: customizable version
numbers
Posted by "Antoine Toulme (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869175#action_12869175 ]
Antoine Toulme commented on BUILDR-438:
---------------------------------------
Prompting for data is not going to cut it for Hudson jobs and the like. You need to pass the parameter as a command line argument, at best.
> 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.
[jira] Commented: (BUILDR-438) Release Task: customizable version
numbers
Posted by "Jean-Philippe Caruana (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (BUILDR-438) Release Task: customizable version
numbers
Posted by "Antoine Toulme (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889198#action_12889198 ]
Antoine Toulme commented on BUILDR-438:
---------------------------------------
With my fix to BUILDR-436, your patch will probably have conflicts.
> 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.
[jira] Resolved: (BUILDR-438) Release Task: customizable version
numbers
Posted by "Antoine Toulme (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (BUILDR-438) Release Task: customizable version
numbers
Posted by "Alexis Midon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889219#action_12889219 ]
Alexis Midon commented on BUILDR-438:
-------------------------------------
No, BUILDR-436 is not impacted. If no -SNAPSHOT, then we still dont increment anything.
The rspecs related BUILDR-436 haven't been touched.
> 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.
[jira] Commented: (BUILDR-438) Release Task: customizable version
numbers
Posted by "Antoine Toulme (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12890555#action_12890555 ]
Antoine Toulme commented on BUILDR-438:
---------------------------------------
That's cool Alexis. Thanks very much for the hard work on this.
> 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.
[jira] Updated: (BUILDR-438) Release Task: customizable version
numbers
Posted by "Alexis Midon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexis Midon updated BUILDR-438:
--------------------------------
Description:
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.
was:
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.
I updated the description to highlight that the output of Release.bump_version is used to update the buildfile and that the buildfile is committed with this new version (like it is already today)
> 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.
[jira] Commented: (BUILDR-438) Release Task: customizable version
numbers
Posted by "Antoine Toulme (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (BUILDR-438) Release Task: customizable version
numbers
Posted by "Antoine Toulme (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/BUILDR-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868751#action_12868751 ]
Antoine Toulme commented on BUILDR-438:
---------------------------------------
I like it. I would offer to document also so that users have a way to specify the new bumped version number from the command line:
buildr release RELEASE_VERSION="my.new.version"
and in the Buildfile:
Release.bump_version = RELEASE_VERSION
That means bump_version must be dealt either as a block or directly as a value.
Alternatively:
Release.bump_version = lambda {|version| RELEASE_VERSION }
Eventually we could use a defined constant (RELEASE_VERSION ?) when no block is passed.
> 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.