El jue, 18-03-2010 a las 08:30 +0100, Adrian Lienhard escribió: > 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. > > Cheers, > Adrian
Yes, I liked this too. Specially the no metacello modifications part. +1 > > > 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 -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
