>From the modules doc site:
> !Repository
> > I imagine 'updates.list' becoming structured, or even merged with the whole 
> > repository mechanism.
>
> I think we could just open "updates" folders in the repository for people to upload into,
> then the "update collectors" will somehow process them, perhaps by merging them 
> into three/four-decimal releases. Someone noted Debian's system of Unstable (a slightly 
> better name for test pilot), Testing (IIRC, used by test pilots for some time with few 
> complaints), and Stable.>

To spell it out (one way this could be done) -
Updates.list can be replaced by a versioned "SqC Full" configuration
living in some repository. The configuration would start by having one
Module - "Squeak base". Creating an update means creating another
version of the module. Releasing updates would mean creating another
version of the configuration, that requires the latest module version.

Then slewing functionality off the image would be pretty trivial -
someone makes a new module called "Celeste", moves all the code to that.
The Harvesters test this is a proper replacement for the code in "SqC
base". If so, they make an "SqC base" version with out the code. The
next version of the configuration "SqC full" will include two modules -
"SqC base", and "Celeste". Voila.

Making and maintaining a PDA image (or StableSqueak image, or 
SqueakNOS with MorphicWrappers and NK's Connectors...) is also
trivial - make another configuration, and when things move to other
modules, be selective about adding them to the configuration.

After we make this change, the "Celeste" module has it's own maintainer,
and the Harvesters just choose when to update the dependency of "SqC
full" to point at the newest (or not) Celeste versions. It's up to module 
maintainers to integrate submitted changes into their modules.

The average joe would only need to pick a configuration he likes, and 
update from it whenever it has a new version.

Does this fit everyone? Dan? Harvesters? Henrik? Other module
maintainers? 

If so -

Everything described is supported by SCAN today. 

A few things are missing to be practical - 
* A mapping to Henrik's modules, so a SCANItem can be identified as a
new version of an image module, and loaded into it. 
* Code to do selective download of versions of Items we don't yet have,
and that use the existing dependencies to get the closure - move from a
configuration to the list of modules required to support them.
* A simple "update what I need from the server and install it" option. 

Daniel

Henrik Gedenryd <Henrik.Gedenryd at lucs.lu.se> wrote:
> I have now created a page on the swiki for building documentation about the
> modules system. Currently it lists the specification that exists, plus
> copies of mail discussions that may be helpful.
[snip]