ok, cool, then lets try to do it this way! Estaban, how can we make Gofer Project Loader to be initialized with MetacelloRepositoryPharo1.0 in a Pharo 1.0 image and the other repository in 1.1 etc.?
Cheers, Adrian On Mar 18, 2010, at 18:14 , Dale Henrichs wrote: > 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
