+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 at 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 at 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 at lists.gforge.inria.fr
| > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
| >