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
