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

Dale Henrichs dhenrich at vmware.com
Fri Apr 29 19:29:38 CEST 2011

On 04/29/2011 01:07 AM, Mariano Martinez Peck wrote:
> Hi Dale. For Pharo 1.3 I want to (try) to use all #stable, i.e, I want
> that ConfigurationOfPharo doesn't explicitly load a specific version of
> every project but instead, the #stable.
> First step I need to do (I will try to do it during the weekend) is to
> update #stable in each of the ConfigurationOf used by
> ConfuigurationOfPharo. That's an easy part.
> Now, my question is...I don't really understand how the confs would look
> like after. I mean, 99% of the cases (in fact, at the beginning it will
> be 100% until I find a problem), the version I use will be #stable.
> So,the version of ConfgiruationOfPharo AND all the Configurations used
> by ConfgiruationOfPharo would look something like this:
>      spec
>                  project: 'Autotest' with: #stable;
>                  project: 'Autotest Help Tests' with: #stable;
>                  project: 'MemoryMonitor' with: #stable;
>                  project: 'XMLSupport' with: #stable;
> I mean...every single project reference will have #stable instead of a
> specific version. So...is this expected? is this the way I should do it ?
> Finally...is there a query I can do to Metacello saying "which are the
> ConfigurationsOf needed for this version for this group of this Conf" ?
> Thanks
> --
> Mariano
> http://marianopeck.wordpress.com


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

Developers interested in getting the "latest released version for all 
projects" in ConfigurationOfPharo would load the baseline version and 
then get the #stable version of all the projects for their platform ... 
each of the projects was know to work by itself in an image (that's what 
the #stable designation means), but the unknown is whether all of the 
projects work together in image ... When you know that, you create a 
literal version of ConfigurationOfPharo to commemorate that set of 

Without looking at the list of projects, it might still make sense to 
use #stable in the literal version, but it would be the exception to the 
rule ...

Does this make sense to you?


More information about the Pharo-project mailing list