George, At the moment there is no overall way to do that for Pharo. For GemStone I have attributes for specific versions, so for GemStone I can write a spec like this: spec for: #common do: [...]. spec for: #gemstone do: [...]. spec for: #'gs2.4.x' do: [...]. spec for: #'gs3.x' do: [...]. So I can specific packages that are only loaded in GemStone 2.4 or GemStone 3.0. For Pharo I would imagine doing something like the following: spec for: #common do: [...]. spec for: #squeakCommon do: [...]. spec for: #pharo do: [...]. spec for: #'pharo1.0' do: [...]. spec for: #'pharo1.1' do: [...]. Then packages that were specific to 1.0 and 1.1 can be specified. I haven't added this to Metacello for Pharo, because I was kind of waiting for the need to appear rather than add a feature that noone needs, so I've been waiting for someone to ask for the feature:) Dale ----- "George Herolyants" <george.herolyants@gmail.com> wrote: | Thanks for the explanation, Dale! | | May be it's obvious and I'm asking stupid questions but then I don't | understand how can I specify in my configuration the differences | between the versions of the target platform? | | 2010/3/20 Dale Henrichs <dale.henrichs@gemstone.com>: | > George, | > | > The mcz files containing the Metacello configurations _are_ copied, | but the configuration itself is not modified in the scheme. | > | > The idea of using different repositories is to indicate which of the | many different projects are _expected_ or _known_ to work in Pharo1.1 | or Pharo1.0. | > | > For GemStone, I have createed a GemSource MetacelloRepository and I | have copied the metacello configurations that I know have been ported | to GemStone. I've done this so that folks can know what is supported. | I make sure that all of the tests run green and that all of the | configs in the GemSource MetacelloRepository can be loaded. | > | > It does not stop someone from loading a configuration into GemStone | that isn't in the GemSource MetacelloRepository, but if you do and run | into trouble, my answer will probably be that it hasn't been ported | yet. | > | > The same thing can apply to Squeak, but someone would have to step | up to testing/approving metacello configurations that run with the | various versions. | > | > Without this extra step of approval/testing, it's difficult for | someone that doesn't have their finger on the pulse of the latest and | greatest happenings to know what to expect ... | > | > Dale