+1 With at least one exception:) In Seaside3.0 there is a tight coupling between the Seaside3.0 packages and the Grease packages ... to the point were (at least for the time being) a later version of Grease is not likely to work an earlier version of Seaside3.0, so it _is_ appropriate to slave the versions together by specifying a version in the baseline ... When Grease/Seaside matures to the point were structural dependencies are no longer being worked out, the need to specify the Grease version in the baseline can (and should) go away. Dale ----- "Mariano Martinez Peck" <marianopeck@gmail.com> wrote: | My advice is not to specify versions in a project reference. | | If you have a baseline and in such baseline you reference a project, | for | example: | | "this piece of code is inside a baselind" | project: 'UI Support' with: [ | | "One or more of the following | attributes may | be defined or changed" | spec | "Name of config class (i.e., | ConfigurationOfXXX)" | className: | 'ConfigurationOfUI'; | "Version of project to be | loaded. if | theversionString is not specified, then the latest version of the | project is | used." | versionString: '1.0'; | | | Then, DO NOT PUT versionString: there. So: | | | "this piece of code is inside a baselind" | project: 'UI Support' with: [ | | "One or more of the following | attributes may | be defined or changed" | spec | "Name of config class (i.e., | ConfigurationOfXXX)" | className: | 'ConfigurationOfUI'; | "Version of project to be | loaded. if | theversionString is not specified, then the latest version of the | project is | used." | file: 'XXX'. | | | And in a version method that has THAT basline, you write: | | spec | project: 'UISupport' with: '1.0'. | | | In summary, don't put version information in baselines, only in | version | methods. That's just my advice. | | Cheers | | Mariano | | | On Thu, May 6, 2010 at 10:13 PM, Torsten Bergmann <astares@gmx.de> | wrote: | | > >Does that mean the documentation is just wrong then? | > | > I would see/interpret it like this: With the baseline you describe a | set of | > packages (structure/dependencies) that form your app/project | (MyApp). Beside | > the usual loading of a version: | > | > (ConfigurationOfMyApp project version: '1.0') load | > | > it is possible to load also a baseline - this would load all the | latest | > Monticello package versions of any package described in this | baseline: | > | > (ConfigurationOfMyApp project version: '1.0-baseline') load | > | > Note that in the baseline you dont say anything about the | Monticello | > package | > version to use/load. | > | > In a baseline you can also define a dependency on another project | (that | > provides a config too, for instance ConfigurationOfMyFoo). | > | > Now you have two options: | > | > a) dont say anything about the version of "ConfigurationOfMyFoo" | in the | > baseline | > => this should load the latest version of Foo's Metacello | > configuration then, | > so you get the latest version of "Foo" when loading the | baseline | > of MyApp | > | > b) you note/give a default version for "ConfigurationOfMyFoo" in | the | > baseline | > => then this specific version of "Foo" is loaded when you load | the | > baseline for MyApp. | > I think you can override the version specified in the | baseline in | > a #versionXXX of MyApp if required | > | > Loading baselines is usefull if you work in a team. If you work on | the | > same baseline you can just load it to be up to date with the latest | > commits of the other team members. | > | > If your dependencies, load order, set of packages/pre-projects | change then | > you typically create a new baseline. | > | > But it is more often the case that you just create new versions | based on | > a baseline. In a versionXXX you pin/mark the Metacello version of | all | > packages/projects version that fit/work together to form this | version. | > | > Maybe Dale is able to correct me if I'm wrong. | > | > Thanks | > Torsten | > | > | > | > -- | > GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! | > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project@lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | >