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 ----- "George Herolyants" <[email protected]> wrote: | 2010/3/18 Adrian Lienhard <[email protected]>: | > Here is yet another way how we could model universes. We just have | multiple Metacello repositories: | > | > - MetacelloRepository is the one that everybody can commit to | (testing universe) | > - MetacelloRepositoryPharo1.0 is the stable universe for Pharo 1.0 | > - MetacelloRepositoryPharo1.1 is the stable universe for Pharo 1.1 | > - etc. | > | > A package always first gets into the testing universe and when it is | known to work in a particular version it is copied into the | appropriate repository. The Gofer Project Loader would just need to | know the repository for the current Pharo version. Like in Debian, one | can add the testing universe to get unstable versions if needed. | > | > This setup would not need any code changes in Metacello and it | allows us to use access rights to assign people to manage the process | and assert a certain level of quality. | | And what if my project is intended to load in Squeak also? Or | gemtone? | Where should I put it? Does this approach imply that there should be | created appropriate repositories? Doesn't this imply duplication of | code between different configurations (which is avoided now using | #common specifier) if the package can be loaded with only minor | changes in all forks? And doesn't this imply removing all the code | related to the fork specifier handling in Metacello? | | Just curious :) | | | George | | _______________________________________________ | 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
