[Pharo-project] [Metacello] Best strategy for ConfigurationOfPharo using #stable
dhenrich at vmware.com
Fri Apr 29 20:34:53 CEST 2011
On 04/29/2011 10:10 AM, Stéphane Ducasse wrote:
>>> 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: [
project: 'ScriptManager' with: [
project: 'Shout' with: [
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
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