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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100509/8c23ae71/attachment.htm