Ok I understand now and I agree.
An installer script or an mcm is not an option because that would always load one fixed configuration.
But this is not what you want when you do not use a Universe?
Not not? I am confused ;-)
but this is not what we want when we do not use a universe.
To be able to properly load Seaside a system that can handle dependencies is a requirement.
so I'm confused I thought that exactly mcm allow to specify exact version.
mcm is a fixed, ordered set of exact package versions. If we wanted to provide mcm files, we needed to create one for every combination of swazoo/kom (2), tests yes/no (2), development tools yes/no (2), scriptaculous yes/no (2), comet yes/no (2), rsrss yes/no (2), ... Imagine, if we wanted to add Magritte and Pier to that. We would soon end up with an infinite number of possible combinations, each encoded in a different mcm file.
But Universe do not have the granularity for following all the small changes. I thought that for the people developing seaside daily you wanted either the latest or been able to go back to exactly one version of a set of components and there the exact version number is a must I do not see the numbering in dependency in Universe.
Exactly, but Seaside users usually don't follow small changes. We expect developers to know about the dependencies and be able to load the packages manually. Furthermore, as soon as a version of the packages is loaded, doing small updates through Monticello is usually no big deal.
There will be a universe for every release (including alpha and beta releases). Seaside users have the possibility to update from one release to the next.
So tell me because I do not understand. I also thought that Mcm was offering a fixed versions and could be used a fixed configmap We could extend it to support **load latest for this component**
We tried to use mcm in the beginning. Unfortunately not even the developers want a fixed set of packages, but have different focuses and therefore different packages loaded. For example, I focus on JavaScript, while Philippe on different encodings and server adapters, ...
So in Universe each package has a list of dependencies to other fixed versions of packages (not strictly, but we use it like this). This allows users to select the parts of Seaside they need (for example kom server, no tests, development tools, scriptaculous support and pier). And boom, Universe automatically builds an ordered list of package versions to load. In this example the list would include the correct versions of Magritte-Core and Magritte-Seaside, even if this was never explicitly declared.
Universes is easier for us, because we don't need to prepare all the possible configurations a user wants. Users just select themselves what they want and the system calculates the prerequisites.
Now with MC2, the story is again completely different ...
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project