Andreas, We're talking conventions here, not hard and fast requirements. The convention is that you create a _baseline_ where you specify the list packages and projects that go into your project including repository info and dependencies. The you create a _version_ that imports a _baseline_ and simply specifies the specific mcz file and project version that goes into the project. As project structure changes, new baselines are created. As new mcz files or project versions are produced, a new version reflecting this new state is released. Separating this out from the beginning just makes it easier (in my opinion) for folks to wrap their minds around the two different concepts... structure of the project and version specification...Which I think is important to understand early on, whether or not you create separate artifacts or not... Dale ----- "Andreas Raab" <andreas.raab@gmx.de> wrote: | On 5/10/2010 10:06 AM, Dale Henrichs wrote: | > +1 | | I'll have to admit I find this quite awkward - like designing a | framework that has only one use case. It tends to push the wrong | things | into the abstraction layer. Is there anything fundamentally wrong with | | creating the baseline only at the point where you have more than one | version to deal with? | | Cheers, | - Andreas | | > 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 | > |> | > | >