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 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" <estebanlm@gmail.com> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project