[Pharo-project] [Metacello] Best strategy for ConfigurationOfPharo using #stable

Stéphane Ducasse stephane.ducasse at inria.fr
Fri Apr 29 20:12:12 CEST 2011


>>> 
>> 
>> when you say that "load the baseline": do you mean that you will get
>> all the latest versions of the seaside packages?
> 
> Yes, I load the baseline version of Seaside30, to pick up the most
> recent checkins by the Seaside developers, so I can update the
> configuration, port the changes, to GemStone and make a release.
> 
> And when I do that, I don't want the latest OmniBrowser packages:)
>> 
>> 
>>> I want to load the #bleedingEdge versions of Grease, Kom, and
>>> Swazoo, because they are part of the project family. I absolutely
>>> don't want to load the latest OmniBrowser code, because who knows
>>> what you'd get...
>>> 
>>> So for the ConfigurationOfPharo, if you followed my rule of thumb,
>>> you would create a baseline version and use the #stable version for
>>> all of the projects in the baseline. In the literal version you
>>> would use the explicit version, so that you'd have an explicit
>>> repeatable specification for a set of projects that were known to
>>> work together.
>> 
>> ok you mean that if people want the latest they load the baseline
>> else they can just use a literal version and access it via #stable
> 
> 
> I'm not sure what you mean here....
> 
> The pharo 1.2.2-baseline would include specs that look like this:
> 
>  spec
>    project: 'OB Dev' with: [
>      spec
>        className: 'ConfigurationOfOmniBrowser';
>        versionString: #stable;
>        ...];
>    project: 'ScriptManager' with: [
>      spec
>        className: 'ConfigurationOfScriptManager';
>        versionString: #stable;
>        ...];
>    project: 'Shout' with: [
>      spec
>        className: 'ConfigurationOfShout';
>        versionString: #stable;
>        ...];
>    ....].
> 
> Loading Pharo 1.2.2-baseline would cause the #stable version for each of those projects to be loaded ... but remember over time the #stable version will change and incompatibilities between packages can creep in. By using #stable versions you will be in better shape than using #bleedingEdge because the #stable version is known to work.
> 
> Pharo 1.2.2 (literal version) will have corresponding specs that look like this:
> 
>  spec
>    project: 'OB Dev' with: '1.2.4';
>    project: 'ScriptManager' with: '1.2';
>    project: 'Shout' with: '1.2.2';
>    ....].
> 
> So that you have driven a stake into the ground stating that these versions are known to work together (have passed tests as a unit). 5 years in the future, you will be able ot load Pharo 1.2.2 and get exactly the same packages every time ... whereas the #stable versions may have drifted over time ...

Excellent point. I should add that to the book chapter!


> If I am just bringing up a PharoCore1.2 image and I'd like to load the Pharo dev code, I should load the #stable version of Pharo (which may be 1.2.2 today and 1.2.3 tomorrow).
> 
> If I want to duplicate the environment that someone is working in I will ask them for th version of Pharo and load that explicit version to reproduce the bug or whatever ...
> 
> Dale




More information about the Pharo-project mailing list