About MC for managing the image

[Andreas Raab]

stéphane ducasse wrote:
> Yes but this is exactly what we were doing with the introduction of  
> morphic splitters. Now I simply cannot load the
> morphic splitters changes since they move classes around and  introduced 
> packages. I think that the script idea
> is not good for package restructuring. Because the morphic splitters  is 
> not complex but still finding the right order is terrible.
> Squeak died on me when I tried to load Morphic-aftermorphicsplitters.  
> And I could NOT try sooner since we got a large
> set of changes from the morphicsplitter team.

A good question is whether Daniel's proposed mechanism would be able to 
deal with this problem.

>> e.g., make a whole set of new package versions, try to load and  
>> figure out where and why it dies.
> 
> But how can we do something else?

Well, generally speaking, having the ability to do a quick check if some 
changes will load okay is certainly critical even if one insists on 
posting configurations explicitly (for which I don't see much of a reason).

For something like splitters change set it's probably worthwhile to 
treat it as a goal and have someone work on figuring out a load-order 
before trying to fold it in (unless Daniel's simu-load is capable to 
deal with it).

>> Early on we looked at using dependencies but they didn't work very  
>> well for what we wanted to do. Most importantly, if you have a  newer 
>> version of a package it will load the older version instead  (VERY bad).
> 
> I think that this is disconnected. The process should be
> - load the latest build
> - check most recent package (or the build should always be the most  
> recent ie. we do not publish individual packages)
> 
> Avi?
> What is your point of view on that.?

Actually, there is something to be said for having a tool to deal with 
updates. What it might do is list all the (dependent) packages that are 
associated with a (master) package and show you which packages are older 
/ up to date / newer than in the configuration. The action to take 
(upgrade, downgrade, leave alone) could be covered by preferences (e.g., 
"never downgrade", "always load exact version"...).

Add to this a way to "update all dependent packages" (which means go out 
and see if there are any newer dependent packages for a master package) 
and I think we've got all the bases covered. Explicit updates for 
cautious people, implicit updates for the adventurous folks.

Cheers,
   - Andreas