ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Archie Cobbs <arc...@dellroad.org>
Subject Re: Please vote: changing the default conflict manager
Date Fri, 24 Sep 2010 14:13:26 GMT
On Thu, Sep 23, 2010 at 11:17 AM, Niklas Matthies <ml_ant-user@nmhq.net>wrote:

> > 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.
>
> > Now suppose we resolve A. If only version 1.0 of Y exists, then ivy
> 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 assumption that any revision greater than 1.0 will automatically be
backward compatible with 1.0 is in my opinion just plain crazy and wrong.
Software changes all the time and things are constantly being broken by
incompatible changes. Most projects in fact have an explicit policy to this
effect, saying for example that any change in the major version number
signifies an incompatible change in the API, etc.

Moreover, this becomes more and more true as a project's dependency tree
gets bigger and more complicated -- exactly the situations where you need
ivy the most.

Finally, if what you want to say is "anything revision 1.0 or later" then we
have the syntax rev="[1.0,)" for that purpose. Having rev="1.0" mean the
same thing is totally counter-intuitive.


> 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.
>

I disagree with this logic. Whether a new version of a module B is
compatible with module A depends on both A and B, not just on B. Therefore,
it cannot be left only to B to specify compatibility.


> 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.
>

Excactly. If you say ">= 1.0" then (obviously) you don't get build
repeatability in the face of new versions. That's perfectly OK!

What bothers me is that if you say "= 1.0" then you ALSO don't get build
repeatability in the face of new versions. This seems wrong -- at least in
so far as this is ivy's default behavior out of the box.


> 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.
>

This would be nice but simply is not sufficient. Whether A is compatible
with a new version of B depends on both A and B. For example, B might have
removed a deprecated Java method. Whether that change is incompatible or not
depends on whether A invokes that method.


> 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.
>

Ivy leaves it up to each module to declare what versions of its dependencies
it is compatible with. This makes sense to me, because you can't just
compute that information automatically, so if it has to be explicitly
declared someplace then the module's <dependencies> is as good a place as
any.

The problem is that ivy's default behavior is (in my opinion) to completely
misread this information. It reads rev="1.0" as "revision >= 1.0".


>  > 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.
>

I don't understand. You are not getting build repeatability... are you
saying that's good?

-Archie

-- 
Archie L. Cobbs

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message