Smalltalk › Pharo › Pharo Smalltalk Users

Adding a #development version of a Git project in the catalog

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Damien Cassou-2

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.html,
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

Uko2

Re: Adding a #development version of a Git project in the catalog

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 <[hidden email]> 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.html,
> 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
>

Damien Cassou-2

Re: Adding a #development version of a Git project in the catalog

Yuriy Tymchuk <[hidden email]> 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

Dale Henrichs-3

Re: Adding a #development version of a Git project in the catalog

On 09/21/2015 06:31 AM, Damien Cassou wrote:
> Yuriy Tymchuk <[hidden email]> 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

Dale Henrichs-3

Re: Adding a #development version of a Git project in the catalog

On 09/21/2015 10:46 AM, Dale Henrichs wrote:

>
>
> On 09/21/2015 06:31 AM, Damien Cassou wrote:
>> Yuriy Tymchuk <[hidden email]> 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

Damien Cassou-2

Re: Adding a #development version of a Git project in the catalog

Dale Henrichs <[hidden email]> writes:

> On 09/21/2015 10:46 AM, Dale Henrichs wrote:
>>
>>
>> On 09/21/2015 06:31 AM, Damien Cassou wrote:
>>> Yuriy Tymchuk <[hidden email]> 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