On Thu 2007-12-13 at 18:22h, Xavier Hanin wrote on ivy-user: > > > On Dec 10, 2007 1:02 PM, Niklas Matthies <[EMAIL PROTECTED]> wrote: > > : > > > > I wonder whether an EarliestCompatibleConflictManager wouldn't > > > > be (even) more useful? It would have the property to yield > > > > reproducible results when newer versions are added to the > > > > repository. : > I'm suggesting to use the resolved ivy.xml to reproduce a build. > Putting it in source control is a good way to do so, but not the > only one. This article is worth reading: > http://dead-parrot.de/ivy/
Thanks for that link. I actually read this some weeks ago, but had forgotten about that point. Let me try to motivate the suggested conflict manager a bit further, though. The approach outlined in the article above makes sense for the creation of patch releases. But we're actually at least as much concerned about stability of dependency resolution during development and testing, where builds happen on the trunk rather than being reproduced builds of frozen versions on a patch branch. That is, even during normal development and testing, we don't necessarily want builds to automatically get some latest revision of a dependee. This is true in particular for dependees that are not part of the project proper (e.g. libraries that are not specific to the project). In these cases we only want to get a later revision if and when the project in question actually requires it, and then we'll define the relevant dependency accordingly. This makes sure that during a build-test-fix-rebuild cycle, the rebuild doesn't introduce new bugs by getting a different revision of some dependee module than the previous build. Now, when specifying dependencies with fixed revisions in the Ivy files, you do get that kind of build stability using the default "latest-revision" conflict manager. If you have a diamond dependency where one path asks for revision 1.5 of a module and the other path asks for revision 1.6, then you'll get revision 1.6, and not some later revision that may have become available. The assumption behind that conflict manager, of course, is that later revisions usually do not break compatibility relative to earlier ones, thus getting revision 1.6 is okay even though one of the dependencies asked for revision 1.5. In other words, "1.5" is effectively treated as the version range "[1.5,)". Given that notion of compatibility, the "lastest-revision" conflict manager applied to fixed revisions is in fact an "earliest-compatible-revision" conflict manager! Specifying a version range with an upper bound, or a sub-revision pattern (i.e. with "+"), on the other hand, quite clearly says that a later revision should not be considered compatible any more. For example, "1.5" might be replaced by "[1.5,2.0[" if version 2.0 breaks compatibility. Then getting revision 1.6 would still be okay, but if the other path in the diamond dependency asks for some revision >=2.0, we want the dependency resolution to fail. This, of course(?), is what the new LatestCompatibleConflictManager will be doing. Only that with it we're losing the build stability the "latest-revision" conflict manager had given us with fixed revisions! If one path asks for "[1.5,2.0[" and the other asks for "[1.6,2.0[", we still want to get revision 1.6 as was previously the case, not revision 1.9 that might also be available. So, I hope I could clarify a bit why I think there ought to be an "earliest-compatible-revision" conflict manager. -- Niklas Matthies
