Adding a #development version of a Git project in the catalog
Hi, I have a BaselineOfJenkins on github and I would like to add a ConfigurationOfJenkins in the catalog. For the #stable versio, I wrote: stable: spec <symbolicVersion: #'stable'> spec for: #common version: '1.0.0' v1_0_0: spec <version: '1.0.0'> spec for: #'common' do: [ spec baseline: 'Jenkins' with: [ spec repository: 'github://DamienCassou/pharo-jenkins:v1.0.0/src' ]; import: 'Jenkins' ] But I don't know what to do for the #development version. I tried this but Metacello does not want it: development: spec <symbolicVersion: #'development'> spec for: #'common' do: [ spec baseline: 'Jenkins' with: [ spec repository: 'github://DamienCassou/pharo-jenkins:master/src' ]; import: 'Jenkins' ] On http://blog.yuriy.tymch.uk/2015/07/pharo-and-github-versioning-revision-2.ht..., Yuriy talks about a pre-release, but this requires changing the #development description for each release. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
Hi, Can you simply define symbolic version as a normal one? I think that you need a baseline with a code of your symbolic version, then you reference this baseline with the #development version and in v1_0_0 you override repository to ââ¦pharo-jenkins:v1.0.0/srcâ. I think that for me that was the main reason why I was doing pre-release. Because you cannot define any changes in symbolic versions, my baseline is a separate class, and âConfigurationOfâ requires semantic versioning. Cheers! Uko
On 21 Sep 2015, at 07:38, Damien Cassou <damien.cassou@inria.fr> wrote:
Hi,
I have a BaselineOfJenkins on github and I would like to add a ConfigurationOfJenkins in the catalog. For the #stable versio, I wrote:
stable: spec <symbolicVersion: #'stable'>
spec for: #common version: '1.0.0'
v1_0_0: spec <version: '1.0.0'>
spec for: #'common' do: [ spec baseline: 'Jenkins' with: [ spec repository: 'github://DamienCassou/pharo-jenkins:v1.0.0/src' ]; import: 'Jenkins' ]
But I don't know what to do for the #development version. I tried this but Metacello does not want it:
development: spec <symbolicVersion: #'development'> spec for: #'common' do: [ spec baseline: 'Jenkins' with: [ spec repository: 'github://DamienCassou/pharo-jenkins:master/src' ]; import: 'Jenkins' ]
On http://blog.yuriy.tymch.uk/2015/07/pharo-and-github-versioning-revision-2.ht..., Yuriy talks about a pre-release, but this requires changing the #development description for each release.
-- Damien Cassou http://damiencassou.seasidehosting.st
"Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
Yuriy Tymchuk <yuriy.tymchuk@me.com> writes:
Can you simply define symbolic version as a normal one?
when I tried I got an error message. Metacello was trying to parse 'development' as a semantic version number.
I think that you need a baseline with a code of your symbolic version, then you reference this baseline with the #development version and in v1_0_0 you override repository to ââ¦pharo-jenkins:v1.0.0/srcâ. I think that for me that was the main reason why I was doing pre-release. Because you cannot define any changes in symbolic versions, my baseline is a separate class, and âConfigurationOfâ requires semantic versioning.
-- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
On 09/21/2015 06:31 AM, Damien Cassou wrote:
Yuriy Tymchuk <yuriy.tymchuk@me.com> writes:
Can you simply define symbolic version as a normal one?
when I tried I got an error message. Metacello was trying to parse 'development' as a semantic version number You can implement #versionNumberClass in your configuration or baseline to switch version number parser to MetacelloVersionNumber which is less picky:)
versionNumberClass ^ MetacelloVersionNumber
On 09/21/2015 10:46 AM, Dale Henrichs wrote:
On 09/21/2015 06:31 AM, Damien Cassou wrote:
Yuriy Tymchuk <yuriy.tymchuk@me.com> writes:
Can you simply define symbolic version as a normal one?
when I tried I got an error message. Metacello was trying to parse 'development' as a semantic version number You can implement #versionNumberClass in your configuration or baseline to switch version number parser to MetacelloVersionNumber which is less picky:)
versionNumberClass ^ MetacelloVersionNumber
So using MetacelloVersionNumber does look like you can define the following version: versionDev: spec <version: 'dev'> spec for: #'common' do: [ spec baseline: 'Jenkins' with: [ spec repository: 'github://DamienCassou/pharo-jenkins:master/src' ]; import: 'Jenkins' ] and then use a standard symbolic version definition: development: spec <symbolicVersion: #'development'> spec for: #'common' version: 'dev' Dale
Dale Henrichs <dale.henrichs@gemtalksystems.com> writes:
On 09/21/2015 10:46 AM, Dale Henrichs wrote:
On 09/21/2015 06:31 AM, Damien Cassou wrote:
Yuriy Tymchuk <yuriy.tymchuk@me.com> writes:
Can you simply define symbolic version as a normal one?
when I tried I got an error message. Metacello was trying to parse 'development' as a semantic version number You can implement #versionNumberClass in your configuration or baseline to switch version number parser to MetacelloVersionNumber which is less picky:)
versionNumberClass ^ MetacelloVersionNumber
So using MetacelloVersionNumber does look like you can define the following version:
versionDev: spec <version: 'dev'> spec for: #'common' do: [ spec baseline: 'Jenkins' with: [ spec repository: 'github://DamienCassou/pharo-jenkins:master/src' ]; import: 'Jenkins' ]
and then use a standard symbolic version definition:
development: spec <symbolicVersion: #'development'> spec for: #'common' version: 'dev'
thank you very much, it helped me a lot. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
participants (3)
-
Dale Henrichs -
Damien Cassou -
Yuriy Tymchuk