So this is what I'm working on - MCConfigurations, by using merge instead of load when it is needed, solve the "older dependency problem" (at least in the context of developers).
However to me the fact that they specify a load order, instead of loading all those versions simultaneously, looks like a bug. The way I've been thinking about ordering issues is that if you need to specify an order because of reference dependencies, that's what simultaneous loading is for. If you need to specify an order for bootstrapping reasons, then you should have a sequence of configurations that each specify a step that works from the previous step, and allow those steps to define the necessary orderings of changes.
So unless there's another reason for the total order, or a problem with one of the above, it seems we can avoid specifying and maintaining a load order, and also be able to load circularly dependent packages.
Of course circularly dependent packages should be eventually dealt with, but that should not determine our upgrade mechanism, especially when MC already handles simu-load.
So I'm proposing to have MCConfigs to use simu-load for users and simu-merge developers, and ignore any specified order. Avi and have sketched the needed changes out, I'll work on it soon.
Daniel
Andreas Raab wrote:
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