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

Mariano Martinez Peck marianopeck at gmail.com
Mon May 2 00:31:52 CEST 2011


So.... I will add versionString: #stable
To all confs directly used by ConfigurationOfPharo.
But that's not enough. I should do the same to each of them...and the whole
tree...shouldn't I ?

Maybe if we set up this, hudson can load the latest baseline instead of
#lastVersion as it is doing now...

Cheers


On Fri, Apr 29, 2011 at 8:34 PM, Dale Henrichs <dhenrich at vmware.com> wrote:

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



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110502/ff350887/attachment.htm>


More information about the Pharo-project mailing list