On Sat, Jul 04, 2009 at 12:18:11PM -0700, Andreas Raab wrote:
> Ken Causey wrote:
> >Oh good, I have to admit I wasn't absolutely sure there wasn't something
> >more I needed to do.
> 
> If the change is local to a single package there is not much you need to 
> do. Monticello is reasonable in this case and the updater will just load 
> the version of the package. Where it gets nasty is:
> 
> * When you rename classes (this may have been addressed in one of the 
> later MC versions?) as Monticello will delete the old class mercilessly, 
> leaving all the instances in the dust

Speaking of deleting things mercilessly, I'm doing some housecleaning to
move a few methods from the base image into the VMMaker package (see
Mantis 7221). These are just some C code generator methods that apparently
were not recatogorized back when the VMMaker package was split out of the
base image. I have added them to the VMMaker package (VMMaker-dtl.125 on
SqueakSource), and have intentially left them in the image (Kernel and
Collections packages on source.squeak.org/trunk) on the theory that other
VMMaker projects will expect to find these methods in the image for some
time to come.

Some time in the future (maybe in 6 months or so) the recategorized methods
will be removed from the trunk project. In the mean time anyone who loads the
latest VMMaker, Kernel and Collections will have an annoying conflict to deal
with.  As far as I know this is an inherently manual process that just requires
some follow up actions, but if there are any Monticello tricks I should be
aware of, please let me know.

Dave