> To see that Monticello is not necessary, consider that Squeak has gone
> through thousands up upgrades at this point by using changeset format.
> Clearly it is possible to make do with changesets!

It's possible for a monolithic image.  I'm not convinced it works for 
multiple packages.  It seems like you could get into some really messy 
ordering stuff if you had two concurrent update streams that were 
modifying some of the same classes.  And the amount of work that Doug & 
co put into managing the Squeak update stream isn't something I would 
want to do for every package I maintain - which is probably why you 
don't see similar streams for anything but the base image (even though 
Andreas posted some code to allow this a while back).

> To see that MC is not sufficient, consider the issue of existing
> instances in the image.  That's a common place to get bitten by
> upgrades, but MC doesn't help with it.  As one example, LargeLists
> changes the definition of PluggableListMorph, and typically there are
> instances of PluggableListMorph active in whatever image it is loaded
> in.  Thus, LargeLists must be careful to handle the upgrade transition.
> In fact there is some careful code in LargeLists to allow for this, and
> no format would have made this work automatically.  The maintainer
> fundamentally needs to be involved in decisions about how to upgrade
> existing instances to new ones.  LargeLists uses changesets, not that 
> it
> matters one way or the other.

This is something MC doesn't address right now, and it's something that 
cannot be addressed automatically, but it's certainly something that 
could be addressed manually within the context of MC.  I fully intend 
to make MC "sufficient" as a system for managing all source code in 
Squeak, including the base image itself.  We're not there yet, and it 
may not get adopted for that purpose, but it will be possible if we 
decide to use it.

> To solve the upgrades issue we should focus less on technical measures,
> and more on lines of communication.

Yes.  Making the barriers to feedback as low as possible is crucial, 
because people (me included) are really bad about ignoring things when 
they break rather than telling someone about it.  It might even be a 
thought to have some kind of automated bug reports on by default - if 
you get a walkback while installing a package the SMLoader could just 
pop up a confirmation before sending the debug log off to the 
maintainer.