Okay, I think I am wrapping my brain around this discussion...Sometimes I can be very thick headed:)
Yes that makes perfect sense ... I was thinking about a different issue (code that can only run in Pharo1.1 for example) ... And the Gofer Project Loader is the perfect place to manage this...independently of Metacello ... Yes! Dale ----- "Stéphane Ducasse" <[email protected]> wrote: | On Mar 18, 2010, at 8:30 AM, Adrian Lienhard wrote: | | > 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. | | Yes this is what I was thinking. | In general the policy for a metacello config is to be in the project | where it belongsto and **copied** to the MetacelloRepository. | | > 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. | | Yes! | | > | > Cheers, | > Adrian | > | > | > On Mar 17, 2010, at 23:41 , Miguel Enrique Cobá Martinez wrote: | > | >> El mié, 17-03-2010 a las 15:20 -0700, Dale Henrichs escribió: | >>> ----- "Esteban Lorenzano" <[email protected]> wrote: | >>> | >>> | > - any idea about how we go to differentiate "stable" and | "unstable" | >>> | | >>> | > universes for each Pharo version? How does the user know which | version | >>> | > is the one he needs for his version of Pharo? Sorry, this is | not | >>> | > directly related to the Gofer Project Loader but I think it is | the next | >>> | > important step towards a working package management system! | >>> | | >>> | No clue... maybe we need to add to Metacello a new "dependence | >>> | dimension", like "minimum version of distribution"... but Dale | can be | >>> | much more helpful than me in this area. | >>> | >>> I imagine that code targetted for specific Pharo versions will be | treated like we treat code targeted for different Smalltalk dialects. | So you would write specs 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: [...]. | >>> | >>> or possibly like the following, if a finer version granularity is | needed: | >>> | >>> spec for: #common do: [...]. | >>> spec for: #squeakCommon do: [...]. | >>> spec for: #pharo do: [...]. | >>> spec for: #'pharo1.0' do: [...]. | >>> spec for: #'pharo1.0-10508' do: [...]. | >>> spec for: #'pharo1.0-10515' do: [...]. | >>> spec for: #'pharo1.1' do: [...]. | >>> spec for: #'pharo1.1-11508' do: [...]. | >>> spec for: #'pharo1.1-11515' do: [...]. | >>> | >>> Dale | >>> | >> | >> umm, no please! | >> | >> There would be a lot of combinations after a while. | >> | >> Why about having a new spec universes message that accept a list | of | >> symbols, each symbol representing a given "universe" of tested | packages. | >> This list will be the only thing to modify when grouping different | >> versions of the same package in different repositories. | >> | >> For example, I start with ConfigurationOfMagma version 1.0r43. Two | weeks | >> later I release ConfigurationOfMagma with support for loading | 1.0r44. | >> Both this versions have been tested on Pharo 1.0. So the both are | >> marked | >> | >> spec universes: #(#pharo10). | >> | >> A week later Pharo 1.1 is released, and I test the configuration on | this | >> new version of pharo. Both work ok. So I modify the line to: | >> | >> spec universes: #(#pharo10 #pharo11) | >> | >> and commit. | >> | >> The tools (GoferProjectLoader) then add functionality to scan this | list | >> and presents the users only the appropriated ones based on the | image the | >> users is querying the repository. | >> | >> Of course this is very simplistic because as the debian model | shows, | >> requires a maintainer of each configuration and the user to report | if a | >> given #pharo11 marked version actually doesn't work. If something | don't | >> work, or a new version is given that works, or the tag #pharo11 is | >> removed from that version effectively removing it from that given | >> universe until bugs are fixed or worked around. | >> | >> What do you think? | >> | >> Cheers | >>> _______________________________________________ | >>> Pharo-project mailing list | >>> [email protected] | >>> | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | >> | >> -- | >> Miguel Cobá | >> http://miguel.leugim.com.mx | >> | >> | >> _______________________________________________ | >> 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 | | | _______________________________________________ | 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
