pattern for configuration definition
Hi camillo I like the pattern damien told me you are applying for your configuration. Could you explain them? I understood: baseline48: spec <version: '4.8-baseline'> spec repository: 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. ⦠spec project: 'Metanool' with: [ spec className: 'ConfigurationOfMetanool'; version: #development; file: 'ConfigurationOfMetanool'; repository: 'http://www.smalltalkhub.com/mc/Moose/Metanool/main' ]. ⦠=> baseline48: spec <version: '4.8-baseline'> spec repository: self repositoryUrlString ⦠spec project: 'Metanool' with: [ spec className: 'ConfigurationOfMetanool'; version: #development; file: 'ConfigurationOfMetanool'; repository: 'http://www.smalltalkhub.com/mc/Moose/Metanool/main' ]. ⦠repositoryUrlString ^ 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. specMetanoolConfiguration: spec spec className: 'ConfigurationOfMetanool'; version: #development; file: 'ConfigurationOfMetanool'; repository: 'http://www.smalltalkhub.com/mc/Moose/Metanool/main' I like the idea to avoid duplication at the configuration level. Now damien mention a dev and stable baseline Stef
Before I get into details, if you create a new Configuration in Pharo, you will get now a pre-filled template with lots of comments. Summary: ======== - only 1 version for development which is updated manually (typically on each new commit) - for the DEV version, there is a DEV baseline - if a new release happens, the dev version and it's baseline are copied, the baseline has the same version number as the first version it was introduced with. - all external projects in separate methods for readability (plus it's easier to change the main repos) It's not much actually, but basically I treat the configuration as normal ST code and avoid duplication :). I hope my explanation is not clear enough. On 2013-08-10, at 04:35, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi camillo
I like the pattern damien told me you are applying for your configuration. Could you explain them? I understood:
baseline48: spec <version: '4.8-baseline'>
spec repository: 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. ⦠spec project: 'Metanool' with: [ spec className: 'ConfigurationOfMetanool'; version: #development; file: 'ConfigurationOfMetanool'; repository: 'http://www.smalltalkhub.com/mc/Moose/Metanool/main' ].
â¦
=>
baseline48: spec <version: '4.8-baseline'>
spec repository: self repositoryUrlString ⦠spec project: 'Metanool' with: [ spec className: 'ConfigurationOfMetanool'; version: #development; file: 'ConfigurationOfMetanool'; repository: 'http://www.smalltalkhub.com/mc/Moose/Metanool/main' ].
â¦
repositoryUrlString ^ 'http://www.smalltalkhub.com/mc/Moose/Moose/main'.
specMetanoolConfiguration: spec
spec className: 'ConfigurationOfMetanool'; version: #development; file: 'ConfigurationOfMetanool'; repository: 'http://www.smalltalkhub.com/mc/Moose/Metanool/main'
I like the idea to avoid duplication at the configuration level. Now damien mention a dev and stable baseline
Stef
Maybe it's already existing, but why not create a GUI to create configurations ? It will be more easier and Camillo's pattern will be respected When i was dealing with configurations on ci, i've seen many configurations and no ones was similar. Force users/dev to create a correct configuration implementing dev/stable is needed. Of course, one of the first step of the ci project is testing if the configuration is correct. Else stop process and throw errors. I already have a similar discussion with Camillo :) 2013/8/10 Camillo Bruni <camillobruni@gmail.com>
Before I get into details,
if you create a new Configuration in Pharo, you will get now a pre-filled template with lots of comments.
Summary: ========
- only 1 version for development which is updated manually (typically on each new commit) - for the DEV version, there is a DEV baseline - if a new release happens, the dev version and it's baseline are copied, the baseline has the same version number as the first version it was introduced with. - all external projects in separate methods for readability (plus it's easier to change the main repos)
It's not much actually, but basically I treat the configuration as normal ST code and avoid duplication :). I hope my explanation is not clear enough.
On 2013-08-10, at 04:35, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi camillo
I like the pattern damien told me you are applying for your configuration. Could you explain them? I understood:
baseline48: spec <version: '4.8-baseline'>
spec repository: 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. ⦠spec project: 'Metanool' with: [ spec className: 'ConfigurationOfMetanool'; version: #development; file: 'ConfigurationOfMetanool'; repository: ' http://www.smalltalkhub.com/mc/Moose/Metanool/main' ].
â¦
=>
baseline48: spec <version: '4.8-baseline'>
spec repository: self repositoryUrlString ⦠spec project: 'Metanool' with: [ spec className: 'ConfigurationOfMetanool'; version: #development; file: 'ConfigurationOfMetanool'; repository: ' http://www.smalltalkhub.com/mc/Moose/Metanool/main' ].
â¦
repositoryUrlString ^ 'http://www.smalltalkhub.com/mc/Moose/Moose/main'.
specMetanoolConfiguration: spec
spec className: 'ConfigurationOfMetanool'; version: #development; file: 'ConfigurationOfMetanool'; repository: ' http://www.smalltalkhub.com/mc/Moose/Metanool/main'
I like the idea to avoid duplication at the configuration level. Now damien mention a dev and stable baseline
Stef
-- Best regards, Douaille Erwan <douaille.erwan@gmail.com>
2013/8/10 Erwan Douaille <douailleerwan@gmail.com>
Maybe it's already existing, but why not create a GUI to create configurations ?
oops, it's called Versionner :)
It will be more easier and Camillo's pattern will be respected
When i was dealing with configurations on ci, i've seen many configurations and no ones was similar.
Force users/dev to create a correct configuration implementing dev/stable is needed. Of course, one of the first step of the ci project is testing if the configuration is correct. Else stop process and throw errors.
I already have a similar discussion with Camillo :)
2013/8/10 Camillo Bruni <camillobruni@gmail.com>
Before I get into details,
if you create a new Configuration in Pharo, you will get now a pre-filled template with lots of comments.
Summary: ========
- only 1 version for development which is updated manually (typically on each new commit) - for the DEV version, there is a DEV baseline - if a new release happens, the dev version and it's baseline are copied, the baseline has the same version number as the first version it was introduced with. - all external projects in separate methods for readability (plus it's easier to change the main repos)
It's not much actually, but basically I treat the configuration as normal ST code and avoid duplication :). I hope my explanation is not clear enough.
On 2013-08-10, at 04:35, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Hi camillo
I like the pattern damien told me you are applying for your configuration. Could you explain them? I understood:
baseline48: spec <version: '4.8-baseline'>
spec repository: 'http://www.smalltalkhub.com/mc/Moose/Moose/main'. ⦠spec project: 'Metanool' with: [ spec className: 'ConfigurationOfMetanool'; version: #development; file: 'ConfigurationOfMetanool'; repository: ' http://www.smalltalkhub.com/mc/Moose/Metanool/main' ].
â¦
=>
baseline48: spec <version: '4.8-baseline'>
spec repository: self repositoryUrlString ⦠spec project: 'Metanool' with: [ spec className: 'ConfigurationOfMetanool'; version: #development; file: 'ConfigurationOfMetanool'; repository: ' http://www.smalltalkhub.com/mc/Moose/Metanool/main' ].
â¦
repositoryUrlString ^ 'http://www.smalltalkhub.com/mc/Moose/Moose/main'.
specMetanoolConfiguration: spec
spec className: 'ConfigurationOfMetanool'; version: #development; file: 'ConfigurationOfMetanool'; repository: ' http://www.smalltalkhub.com/mc/Moose/Metanool/main'
I like the idea to avoid duplication at the configuration level. Now damien mention a dev and stable baseline
Stef
-- Best regards,
Douaille Erwan <douaille.erwan@gmail.com>
-- Best regards, Douaille Erwan <douaille.erwan@gmail.com>
participants (3)
-
Camillo Bruni -
Erwan Douaille -
Stéphane Ducasse