On Thu 2010-09-23 at 10:03h, Archie Cobbs wrote on ivy-user: [snip] > Now suppose we resolve A. If only version 1.0 of Y exists, then ivy > will choose Y=1.0 and everything is fine. Now suppose a few months > later version 2.0 of Y is released and added to the repository. The > next time A is resolved, ivy will choose version Y=2.0... even though > the dependency in module A specifically states rev="1.0" for Y.
Well, in my understanding rev="1.0" has always rather meant "some revision compatible with revision 1.0", and the implicit assumption is made that revisions > 1.0 are compatible in that way. While the latter assumption is objectable, the first part is fine, IMO, so "1.0" does NOT mean "exactly 1.0 and no other revision". The compatibility assumption can be made explicit in Ivy, as in "[1.0,)". There are two problems with that, though. The first problem is that it is being declared by the depending module, instead of the dependee module, although the latter knows better which of its later revisions are actually compatible with earlier revisions. The other problem is that (by default) "[1.0,)" gets you the latest revision, so the result of dependency resolution can change even though the dependency declarations of the module revisions involved don't change. Unlike with "1.0", you don't have build stability or build repeatability with "[1.0,)" when newer revisions are added. This is actually pretty much the issue that you're describing above (except that you seem to want "= 1.0" whereas I'm fine with ">= 1.0"). It would make more sense if modules would themselves declare which of their revisions are compatible with which other revisions (by default: compatible with all earlier revisions), and the revisions specified by depending modules would by default always be taken as "or some compatible revision", and dependency resolution would always respect these compatibility constraints. A strategy would only serve to specify which set of revisions to choose among those that meet all compatibility constraints. But at is currently is, compatibility in Ivy is only implicitly defined by a combination of what depending modules declare and which conflict-managers are applied. IMO Ivy's model is somewhat broken in that respect. > To me this seems completely insane... at least for being the > *default*behavior of ivy. > > However, this is just my opinion... and fixing it would mean changing ivy's > default behavior in a backward-incompatible manner, by changing the default > conflict manager from "latest-revision" to "latest-compatible". > > So the question is: would you support this change, or would it be too > disruptive (or you just don't like it, etc.)? Due to the build repeatability argument noted above, we would continue to use "1.0" to mean ">= 1.0", and with a conflict manager using latest-revision. Hence I would prefer for the default to remain as-is. -- Niklas Matthies
