Hi -
The implications with this setup is that we have to produce often an image (validate a configuration of changes working together) and this can be quite painful. At least they are a lot of try and error when there are a lot of dependencies between packages.
In my experience that's a sign that a) you haven't found a good package structure and/or b) you don't test early enough. In the first case the effect is that higher-level changes get intermangled with lower-level changes (that do in fact require careful folding into a running system). An indication towards that point is the effect that the Kernel package has (I think) the most revisions, where clearly it is one of the most stable packages (if it isn't we're in big trouble) and should have the least number of modifications. The same is probably true for Morphic at this point - you *need* a better package structure for Morphic which makes clear when you touch the critical parts (requiring very careful testing) and when the non-critical ones. In comparison, in Tweak I can typically tell by just looking at the package name whether this will require any effort to make sure it loads correctly or not.
It is also really important to test "early enough" whether you can load a package or not after you've done a modification. Unfortunately, you guys are somewhat handicapped since you don't have an automatic default update mechanism like we're using in Tweak. When I post a new version of a package that has even the slightest chance to affect anything I immediately get a fresh image, hit update and test it. Cost me perhaps twenty seconds but if it doesn't work I can easily either post an appropriate configuration or make a change to the package to make it load and post a new version of the package. I really couldn't imagine to work like you do, e.g., make a whole set of new package versions, try to load and figure out where and why it dies.
Bert I have the impression that using package dependencies with a root package (ie havgin Squeak and all the image package as required) would help to minimize inter package dependencies, now why do you use your script (the explicit list of packages) instead of required package. Is it because you can push that in the update stream?
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). There were also some serious issues with nested dependencies (Bert and I had a lot of fun figuring that out). And keep in mind that dependencies are not as good as a load-order since they typically only specify a partial relation (A dependsOn: X and B dependsOn: X does not specify whether A is loaded before B or vice versa) whereas we wanted to make sure that the updating process uses a single well-defined load order for everyone.
Cheers, - Andreas