Dale,

Indeed, tags such as pharo1.0, pharo1.1, pharo1.2, etc. will likely be needed 
for some packages when we have universes for different Pharo versions.

Cheers,
Adrian

On Mar 20, 2010, at 20:45 , Dale Henrichs wrote:

> 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" <[email protected]> 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 <[email protected]>:
> | > 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
> 
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to