ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Matthies <ml_ivy-u...@nmhq.net>
Subject Re: Question about revision conflicts during resolve/retrieve
Date Thu, 13 Dec 2007 19:02:39 GMT
On Thu 2007-12-13 at 18:22h, Xavier Hanin wrote on ivy-user:
> > > On Dec 10, 2007 1:02 PM, Niklas Matthies <ml_ivy-user@nmhq.net> 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

Mime
View raw message