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