You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@buildr.apache.org by "Jean-Philippe Caruana (JIRA)" <ji...@apache.org> on 2013/10/08 17:43:43 UTC
[jira] [Updated] (BUILDR-682) doc: specify my own version number
scheme
[ https://issues.apache.org/jira/browse/BUILDR-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jean-Philippe Caruana updated BUILDR-682:
-----------------------------------------
Attachment: 0001-Fixed-own-version-number-scheme-documentation.patch
attached patch 0001-Fixed-own-version-number-scheme-documentation.patch : I give up all my rights on this (couldn't find the checkbox for that)
> doc: specify my own version number scheme
> -----------------------------------------
>
> Key: BUILDR-682
> URL: https://issues.apache.org/jira/browse/BUILDR-682
> Project: Buildr
> Issue Type: Documentation
> Components: Site/documentation
> Affects Versions: 1.4.12
> Reporter: Jean-Philippe Caruana
> Priority: Minor
> Attachments: 0001-Fixed-own-version-number-scheme-documentation.patch
>
>
> in the page http://buildr.apache.org/releasing.html in the "How to
> specify my own version number scheme" section, I think I found an error:
> # 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
> This will not work for several reasons :
> - syntax error on @VERSION_NUMBER@.split (I don't know that
> @VERSION_NUMBER@ means, maybe someone could explain it to me or give me
> a pointer)
> - "new_version[0] + 1" will not work since new_version[0] in a string
> - it returns an array instead of a string (commit message : Changed
> version number to ["1", 2, "0-SNAPSHOT"])
> $ buildr release
> (in /home/jp/src/perso/presentation_buildr/exemple, development)
> Buildr aborted!
> SyntaxError :
> /home/jp/src/perso/presentation_buildr/exemple/buildfile:15: syntax
> error, unexpected $undefined, expecting keyword_end
> new_version = @VERSION_NUMBER@.split /\./
> ^
> /var/lib/gems/1.9.1/gems/buildr-1.4.12/lib/buildr/core/application.rb:424:in
> `raw_load_buildfile'
> /var/lib/gems/1.9.1/gems/buildr-1.4.12/lib/buildr/core/application.rb:225:in
> `block in load_buildfile'
> /var/lib/gems/1.9.1/gems/buildr-1.4.12/lib/buildr/core/application.rb:220:in
> `load_buildfile'
> This works on my machine, but maybe this is not the original idea :
> Release.next_version = lambda do |this_version|
> new_version = VERSION_NUMBER.split /\./
> new_version[0] = new_version[0].to_i + 1
> #new_version[1] = 0
> #new_version[2] = "0-SNAPSHOT"
> new_version.join '.'
> end
> $ buildr release test=no
> (in /home/jp/src/perso/presentation_buildr/exemple, development)
> (in /home/jp/src/perso/presentation_buildr/exemple, development)
> Cleaning exemple
> Building exemple
> Compiling exemple:A into
> /home/jp/src/perso/presentation_buildr/exemple/A/target/classes
> Skipping tests for exemple:A
> Packaging exemple-A-1.3.0.jar
> Compiling exemple:B into
> /home/jp/src/perso/presentation_buildr/exemple/B/target/classes
> Packaging exemple-A-1.3.0.jar
> Compiling exemple:B into
> /home/jp/src/perso/presentation_buildr/exemple/B/target/classes
> Compiling exemple:D into
> /home/jp/src/perso/presentation_buildr/exemple/D/target/classes
> Skipping tests for exemple:B
> Packaging exemple-B-1.3.0.jar
> Skipping tests for exemple:D
> Packaging exemple-D-1.3.0.jar
> Compiling exemple:C into
> /home/jp/src/perso/presentation_buildr/exemple/C/target/classes
> Skipping tests for exemple
> Skipping tests for exemple:C
> Packaging exemple
> Packaging exemple-C-1.3.0.war
> Deploying packages from exemple
> Deploying barreverte.fr:exemple-A:pom:1.3.0
> Deploying barreverte.fr:exemple-A:jar:1.3.0
> Deploying barreverte.fr:exemple-B:pom:1.3.0
> Deploying barreverte.fr:exemple-B:jar:1.3.0
> Deploying barreverte.fr:exemple-D:pom:1.3.0
> Deploying barreverte.fr:exemple-D:jar:1.3.0
> Deploying barreverte.fr:exemple-C:pom:1.3.0
> Deploying barreverte.fr:exemple-C:war:1.3.0
> Completed in 2.620s
> Committing buildfile with version number 1.3.0
> Counting objects: 7, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (4/4), done.
> Writing objects: 100% (4/4), 373 bytes, done.
> Total 4 (delta 3), reused 0 (delta 0)
> To git@github.com:jpcaruana/presentation_buildr.git
> 4960c6c..5a5958b test_buildr_release -> test_buildr_release
> Tagging release 1.3.0
> error: tag '1.3.0' not found.
> remote: warning: Deleting a non-existent ref.
> To git@github.com:jpcaruana/presentation_buildr.git
> - [deleted] 1.3.0
> Counting objects: 1, done.
> Writing objects: 100% (1/1), 191 bytes, done.
> Total 1 (delta 0), reused 0 (delta 0)
> To git@github.com:jpcaruana/presentation_buildr.git
> * [new tag] 1.3.0 -> 1.3.0
> Current version is now 1.4.0-SNAPSHOT
> Counting objects: 7, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (4/4), done.
> Writing objects: 100% (4/4), 393 bytes, done.
> Total 4 (delta 3), reused 0 (delta 0)
> To git@github.com:jpcaruana/presentation_buildr.git
> 5a5958b..ac06f56 test_buildr_release -> test_buildr_release
> Completed in 10.031s
> I also found that
> project.version = THIS_VERSION
> is not necessary (see my test at
> https://github.com/jpcaruana/presentation_buildr/tree/test_buildr_release)
> ps: using 'buildr release next_version="2.0.0-SNAPSHOT"' overrides
> Release.next_version = lambda in the buildfile : that's neat !
> ps2: I found the message "error: tag '1.3.0' not found." disturbing
> since this is an expected behaviour. An already existing tag is an issue
> and the build should fail - in facts, it fails on the upload part. Maybe
> buildr could fail faster by checking tag existence before
> compile/test/package/upload.
--
This message was sent by Atlassian JIRA
(v6.1#6144)