Hi Stef -
I would like to see how we can manage gradually the image via MC so may be we will have several back and worth into the update streams. People willing to help are welcome.
Actually, I think we've nailed this problem in Tweak by using the right mixture of packages and updates. If you haven't looked at it, here is how it works: In Tweak, *all* code is in packages[*]. Updates are exclusively used for in-image reshapes, e.g., when part of the system has undergone significant changes that require manual intervention. In order to synchronize these modifications with the package versions that we expect, we typically post a configuration map, e.g., a list of packages where we expect some specific version to be present.
When you update, we always consult the update stream first. This will suck in any intermediate configurations and perform the necessary in-image modifications. Once this is done, we merely upgrade all packages in a well-defined order to their latest version.
[*] The one exception from that rule being code that needs to modify existing Squeak code which doesn't come in packages. Since overrides are evil we leave these changes alone in the updates. What we *should* be doing here (if Squeak were in packages) is to maintain our own branches of the packages in question. As a matter of fact I started looking into this issue lately - if you check out http://source.impara.de/iSqueak.html you'll find a small change set for reorganizing Squeak 3.8 (6662) so that *all* code is in packages (look at the wiki page for reference).
Personally, I think this is the way to go - we have used this for several months in Tweak and besides some screwups that we're responsible for we definitely haven't found any fundamental flaw in this setup.
Cheers, - Andreas