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
