Colin said:

"Yeah. I probably shouldn't have stated it that strongly. Our "live systems"
at the time were web apps with data stored in an external database. So if by
"maintaining live systems" you mean updating the code without out taking
down the app, yeah. If you also mean "and migrating in-image objects
transparently," well no, not quite.

On the other hand, truly "live systems" are a big part of what this
community does, and I personally would like to see Monticello do a better
job of serving that part of the community. "

A module/version manager such as Monticello can't by itself deal with every
issue that might arise in "hot loading" a new version of a module (or module
graph) on top of an already-resident version.  Either the classes in the
modules have to be designed to handle that, or else some sort of contraint
system must be used to ensure that the contraints declaratively specified
for each version of a class or module are satisfied (such as certain
instance variables not being nil.) Actually, the same is true of using
change sets: the change set has to include whatever code (and "do its") are
necessary to fix up whatever issues may be created by the change to the live
system.

A lot (but certainly not all) of the pain people experience when using
module/version management systems is ultimately due to the fact that the
classes they are changing weren't designed to properly interact with the way
module/version managers do business.  And the programmers may not be used to
the module/version manager paradigm. The "change model" is fundamentally
different.

In the change set paradigm, classes are sent the message #initialize when
first loaded.  Change sets may need to send the #initialize message to one
or more already-resident classes, and may need to send other messages to
either classes or other non-class instances.  It is the responsibility of
the change set author to ensure that the necessary "do its" are included,
and that they get executed at the appropriate moment.  Of course, there is
an O(n^2) issue here, in that the "repair logic" may need to be different
for every combination of source and targert version.

In the module/version manager paradigm, one must not only send #initialize
(or whatever the canonical message name may be) to classes when first
loaded, one must also be able to canonically inform each class, each module
and each meta-module (if such exist) that it has been (and is about to be)
changed to a new version, so that whatever "fix up" procedure may be
necessary can be executed. The "version change repair" logic may need to
differ for each version of each class, each module and each meta-module.

So the "change model" when using a module/version manager is fundamentally
different than the one associated with change sets, and requires
architectural and design differences in the code being "managed."  It puts
the responsibility for dealing with "live updates" squarely on the shoulders
of the authors/maintainers of the code, and does not permit the issue to be
just an afterthought that is only dealt with when constructing a change set.

In my experience, one can handle all the same sorts of live updates using
the module/version manager paradigm that one can handle when using change
sets--but only in conjuction with the appropriate architecture and design of
the application/library/system code under management.

--Alan