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

Dale Henrichs dhenrich at vmware.com
Fri Apr 29 20:34:53 CEST 2011

On 04/29/2011 10:10 AM, Stéphane Ducasse wrote:
> dale
>>> My rule of thumb for a literal version spec is that you should
>>> use the #stable symbolic version if the project is loosely
>>> coupled to your project and a specific version otherwise.
>>> OmniBrowser tends to be loosely coupled as you are interested in
>>> getting any old version of OmniBrowser as long as it functions on
>>> the platform.
>> The rule of thumb for a baseline version spec is to use #stable for
>> all projects (as long as the #stable version is defined), even
>> "tightly coupled" projects. When the baseline version is loaded,
>> you normally don't want to load the "latest code" or all of the
>> projects that you depend upon.
>> The #bleedingEdge symbolic version should be used only when the
>> referenced project is part of your project family.
>> When I load the baseline version for Seaside30,
> 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:

     project: 'OB Dev' with: [
         className: 'ConfigurationOfOmniBrowser';
         versionString: #stable;
     project: 'ScriptManager' with: [
         className: 'ConfigurationOfScriptManager';
         versionString: #stable;
     project: 'Shout' with: [
         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:

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

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


More information about the Pharo-project mailing list