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 ...
Excellent point. I should add that to the book chapter!
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