A long, long time ago, in response to goran.hultgren at bluefish.se I wrote the
following about my ideas for modular updates:

I hoped that modules and a reshaped update process would become the basis
for a new, more democratic/open organization around Squeak. The significance
of this goes deeper than just a new file distribution vehicle. These are my
thoughts:

- Anyone should be able to create their own module, they then become the
owner of its repository (and in charge of it). Any module should be able to
have an independent update process, essentially "owned" by the module owner
but often delegated to a harvester (group).

- There ought to be no asymmetry in this system, e.g. no disadvantages in
not being part of an "official" Squeak distribution, and no privileged
access other than to he parts you "own". If you need to modify Object, then
use DeltaModules in your own module.

The best metaphor for my idea of an update scheme is Usenet news.

- Any module owner could open an "official" update channel for the module,
corresponding to a moderated newsgroup (moderator = owner or delegated
harvester(s)). Updates will correspond to new versions of the module, so the
version number is the update number.

- The owner could also create an open contribution channel, working as an
unmoderated news group, or a "drop box", where anyone could drop ENHs,
FIXes, goodies, etc. (Compare to list postings today.) There could also be a
bug tracking facility. Here anyone is free to browse everything, and load
things to try them; there are no numbers here. The owner/harvester(s) can
take pieces from this channel and integrate them into new official versions,
this corresponds to fixes becoming official updates, with some guarantee for
conflicts being resolved etc.

- Every user could essentially subscribe to any channel, to be notified
about additions and to have updates from certain channels (typically
moderated) be loaded, but not from others.

This system is a blend of 1) what we have today, but with completely
decentralized updates and much more convenient loading and distribution, and
2) the features of the Debian system: Debian-stable would correspond to
official x.x image releases, Debian-testing would be the moderated update
channel. Perhaps you could also say "only load new versions that have been
out for N (e.g. 14) days". Debian-unstable would correspond to browsing
through what people drop into the open channel.

Somehow I would like to be able to load bugfixes to a module without also
getting new features, but I haven't been able to find a way to do this
effortlessly. I think that someone always must make the effort of keeping
them apart as two parallel branches, either the module maintainer does it,
or the module users do it by trying to electively pick what they need. But
hopefully organizing updates per module will alleviate some of these
problems.
 

A possible plan of action:

I think we need to transition gradually to a per-module update system based
on DeltaModules. Whereas we could start opening various "update channels"
related to modules (at first just to experiment with this scheme), we would
need to keep the option open for releasing regular change sets, when DMs
aren't good enough at the time. Then this stream would slowly trickle off.

The question is whether also change sets should become module-related, or
whether we should keep them "global".

> When Dan decides that the Collection module should be released as a new
> revision containing the fix he would do that and... Well, what happens
> then... Henrik? Probably we just load the new Collection module and
> since the delta we already had loaded was for the older revision it
> would be deactivated when the new Collection module revision is
> activated.

Cf. the above difference between unmoderated, non-versioned contributions
and moderated, versioned updates.

> If we view the module "Org/SqueakCentral/baseUpdates" as a "channel"
> module (only convention, not a new type of module or anything) we could
> have several of these. For example, there could be a separate one for
> Celeste or Morphic and even I could set one up if I wanted to at
> "People/gh/SqueakCVS/updates" or whatever.

Yes I think it is more logical to have update channels be organized with the
modules rather than under a single Channels heading, but I don't have a very
strong bias toward either. I.e. probably People/gh/SqueakCVS/Contributions
and rather than Channels/People/gh/SqueakCVS. Since "official updates" are
just new module versions they don't need their own directory, I think.

Henrik