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