Hi folks,

What about preambles and postscripts in versions of Monticello-packages?

Let's state an example: We have a package named Foo, with the versions
Foo1, Foo2, Foo3, Foo4 and Foo5.

Foo3 and Foo5 versions have preamble and/or postscript.

If you have loaded Foo1 and you want to update to Foo5, version Foo3 has
to be loaded before loading Foo5.

This solution will force to load the intermediate versions where a
preamble/postscript exists, but it's not a big problem.

We need to load the intermediate versions to be sure the
preamble/postscript execute in a predictable way.

BTW This proposal don't include a fix for the class-renaming problem.

Cheers,

-- Diego


> On Mar 13, 2006, at 2:59 PM, Andreas Raab wrote:
> 
> > Cees de Groot wrote:
> >> Personally, I would point my finger at the use of MC instead of MC
> >> itself (MC seems to be not fit for a particular purpose its creators
> >> probably never reckoned with).
> >
> > According to Colin "Monticello was designed with maintaining live  
> > system in mind" (see http://lists.squeakfoundation.org/pipermail/ 
> > squeak-dev/2006-February/101067.html)
> 
> 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. As Avi mentioned,  
> Monticello2 has been moving very, very slowly forward for the last  
> year (2 years is a bit of an exaggeration). I honestly think, though,  
> that it's the best vehicle for addressing these issues. I'm going to  
> keep pushing it forward, hopefully making faster progress than I have  
> been.
> 
> Colin