You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Archie Cobbs <ar...@dellroad.org> on 2010/09/23 17:03:45 UTC
Please vote: changing the default conflict manager
In my opinion, the default behavior of ivy is very non-intuitive and
violates POLA <http://en.wikipedia.org/wiki/Principle_of_least_astonishment>
.
I'm referring specifically to the default conflict manager being
"latest-revision" instead of "latest-compatible".
For a concrete example of what this means, suppose we have modules A, X and
Y with these dependencies:
A:
<dependency name="X" rev="3.0"/>
<dependency name="Y" rev="1.0"/>
X:
<dependency name="Y" rev="[1.0,)"/>
Y:
No dependencies
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.
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.)?
Thanks,
-Archie
--
Archie L. Cobbs
RE: Please vote: changing the default conflict manager
Posted by James Davis <ja...@atsid.com>.
Ok, I see what you are talking about.
Resolving X on its own should yield a Y rev 2.0, however if you do a resolve on A Y rev 1.0 should be pulled instead (because A is 1.0 explicitly).
Yes, I agree with the confusion point on that. Additionally if there were non-backwards compatible changes from Y 1.0 to 2.0, then the build would break at this point.
James Davis * QA Engineer II/Software Engineer
Applied Technical Systems, Inc. * Information Engineering
web: www.atsid.com * e-mail: james.davis@atsid.com
(p) 360.698.7100 x241 * (f) 360.698.7200
-----Original Message-----
From: archie.cobbs@gmail.com [mailto:archie.cobbs@gmail.com] On Behalf Of Archie Cobbs
Sent: Thursday, September 23, 2010 8:57 AM
To: ivy-user@ant.apache.org
Subject: Re: Please vote: changing the default conflict manager
You're right that the dependency from X -> Y says rev="[1.0,)" butt he
dependency from A -> Y says rev="1.0". Since we're talking about resolving
A, I would expect "1.0" to be the right choice since it satisfies A's
constraint, not "2.0", which does not.
-Archie
On Thu, Sep 23, 2010 at 10:32 AM, James Davis <ja...@atsid.com> wrote:
> To me, the current default behavior makes sense. The dependency for X is
> listed as 1.0 (inclusive) or newer, not 1.0 explicitly. I myself would find
> it confusing and surprising if it resolved to 1.0 if 2.0 was available.
>
> James Davis * QA Engineer II/Software Engineer
> Applied Technical Systems, Inc. * Information Engineering
> web: www.atsid.com * e-mail: james.davis@atsid.com
> (p) 360.698.7100 x241 * (f) 360.698.7200
>
> -----Original Message-----
> From: archie.cobbs@gmail.com [mailto:archie.cobbs@gmail.com] On Behalf Of
> Archie Cobbs
> Sent: Thursday, September 23, 2010 8:04 AM
> To: Ivy Users
> Subject: Please vote: changing the default conflict manager
>
> In my opinion, the default behavior of ivy is very non-intuitive and
> violates POLA <
> http://en.wikipedia.org/wiki/Principle_of_least_astonishment>
> .
>
> I'm referring specifically to the default conflict manager being
> "latest-revision" instead of "latest-compatible".
>
> For a concrete example of what this means, suppose we have modules A, X and
> Y with these dependencies:
>
> A:
>
> <dependency name="X" rev="3.0"/>
> <dependency name="Y" rev="1.0"/>
>
> X:
>
> <dependency name="Y" rev="[1.0,)"/>
>
> Y:
>
> No dependencies
>
> 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.
>
> 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.)?
>
> Thanks,
> -Archie
>
> --
> Archie L. Cobbs
>
--
Archie L. Cobbs
Re: Please vote: changing the default conflict manager
Posted by Archie Cobbs <ar...@dellroad.org>.
You're right that the dependency from X -> Y says rev="[1.0,)" butt he
dependency from A -> Y says rev="1.0". Since we're talking about resolving
A, I would expect "1.0" to be the right choice since it satisfies A's
constraint, not "2.0", which does not.
-Archie
On Thu, Sep 23, 2010 at 10:32 AM, James Davis <ja...@atsid.com> wrote:
> To me, the current default behavior makes sense. The dependency for X is
> listed as 1.0 (inclusive) or newer, not 1.0 explicitly. I myself would find
> it confusing and surprising if it resolved to 1.0 if 2.0 was available.
>
> James Davis * QA Engineer II/Software Engineer
> Applied Technical Systems, Inc. * Information Engineering
> web: www.atsid.com * e-mail: james.davis@atsid.com
> (p) 360.698.7100 x241 * (f) 360.698.7200
>
> -----Original Message-----
> From: archie.cobbs@gmail.com [mailto:archie.cobbs@gmail.com] On Behalf Of
> Archie Cobbs
> Sent: Thursday, September 23, 2010 8:04 AM
> To: Ivy Users
> Subject: Please vote: changing the default conflict manager
>
> In my opinion, the default behavior of ivy is very non-intuitive and
> violates POLA <
> http://en.wikipedia.org/wiki/Principle_of_least_astonishment>
> .
>
> I'm referring specifically to the default conflict manager being
> "latest-revision" instead of "latest-compatible".
>
> For a concrete example of what this means, suppose we have modules A, X and
> Y with these dependencies:
>
> A:
>
> <dependency name="X" rev="3.0"/>
> <dependency name="Y" rev="1.0"/>
>
> X:
>
> <dependency name="Y" rev="[1.0,)"/>
>
> Y:
>
> No dependencies
>
> 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.
>
> 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.)?
>
> Thanks,
> -Archie
>
> --
> Archie L. Cobbs
>
--
Archie L. Cobbs
RE: Please vote: changing the default conflict manager
Posted by James Davis <ja...@atsid.com>.
To me, the current default behavior makes sense. The dependency for X is listed as 1.0 (inclusive) or newer, not 1.0 explicitly. I myself would find it confusing and surprising if it resolved to 1.0 if 2.0 was available.
James Davis * QA Engineer II/Software Engineer
Applied Technical Systems, Inc. * Information Engineering
web: www.atsid.com * e-mail: james.davis@atsid.com
(p) 360.698.7100 x241 * (f) 360.698.7200
-----Original Message-----
From: archie.cobbs@gmail.com [mailto:archie.cobbs@gmail.com] On Behalf Of Archie Cobbs
Sent: Thursday, September 23, 2010 8:04 AM
To: Ivy Users
Subject: Please vote: changing the default conflict manager
In my opinion, the default behavior of ivy is very non-intuitive and
violates POLA <http://en.wikipedia.org/wiki/Principle_of_least_astonishment>
.
I'm referring specifically to the default conflict manager being
"latest-revision" instead of "latest-compatible".
For a concrete example of what this means, suppose we have modules A, X and
Y with these dependencies:
A:
<dependency name="X" rev="3.0"/>
<dependency name="Y" rev="1.0"/>
X:
<dependency name="Y" rev="[1.0,)"/>
Y:
No dependencies
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.
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.)?
Thanks,
-Archie
--
Archie L. Cobbs
Re: Please vote: changing the default conflict manager
Posted by Carl Myers <cm...@palantir.com>.
Sadly, right now, it seems broke =(
https://issues.apache.org/jira/browse/IVY-1228
To go ahead and give one anecdote, our dependency graphs are *very*
complicated. We have two kinds of builds, "official" builds built by
our continuous build (and continuous release) process, and local
developer builds to "test before committing".
Because our continuous release is releasing all the time, a local build
fails because each module does its own resolve, which will resolve
different dependencies (since the dependencies are in a constant state
of flux). If, however, latest-compatible was in use, then the correct
version should be used (because previously built modules would mean a
transitive dependency on 1.0 which would lock us into 1.0, even though
1.1 has been released since the start of the build).
Our usecase is probably atypical, very few people have dependency graphs
as complex as ours, but it is a data point for you. We use strict
dependency checking in our continuous build (and wherever possible) but
we really need latest-compatible for our local builds for the above reasons.
-Carl
On 09/23/2010 09:49 AM, Mitch Gitman wrote:
> Please forgive the tangent. Here's what the documentation has to say about
> "latest-compatible":
> this conflict manager selects the latest version in the conflicts which can
> result in a compatible set of dependencies. This means that in the end this
> conflict manager does not allow any conflict (like the strict conflict
> manager), except that it follows a best effort strategy to try to find a set
> of compatible modules (according to the version constraints)
>
> http://ant.apache.org/ivy/history/latest-milestone/settings/conflict-managers.html
>
> Can anyone out there articulate precisely what that means?
--
Carl Myers
Palantir Technologies | Internal Tools Software Engineer
cmyers@palantir.com
Re: Please vote: changing the default conflict manager
Posted by Mitch Gitman <mg...@gmail.com>.
Please forgive the tangent. Here's what the documentation has to say about
"latest-compatible":
this conflict manager selects the latest version in the conflicts which can
result in a compatible set of dependencies. This means that in the end this
conflict manager does not allow any conflict (like the strict conflict
manager), except that it follows a best effort strategy to try to find a set
of compatible modules (according to the version constraints)
http://ant.apache.org/ivy/history/latest-milestone/settings/conflict-managers.html
Can anyone out there articulate precisely what that means?
Re: Please vote: changing the default conflict manager
Posted by Archie Cobbs <ar...@dellroad.org>.
Glad to hear people are thinking about this and have opinions.
On Thu, Sep 23, 2010 at 11:11 AM, Mitch Gitman <mg...@gmail.com> wrote:
> Frankly, I'm very happy that "latest-revision" is the default. I like it
> when a framework or component does the "dumb" or literal thing rather than
> the "smart" or magical thing. If you're being undisciplined about how you
> manage your dependencies, then I appreciate it that Ivy isn't automatically
> trying to think things through for you and bail you out.
>
Maybe that's my problem, I'm too disciplined about my dependencies :-)
To put it simply, here's what I don't like: I say rev="1.0" but ivy gives me
2.0 without any warning and for no good reason. I just think that's wrong.
If I wanted rev="[1.0,)" then I would have said that!
> Archie, isn't the example you give a classic case of why there's
> force="true"? And BTW, while I like that dependencies have a force option,
> I
> chafe at using it. That's an indication to me that I don't have a full
> handle on my repository's dependency graphs.
>
Yes, force=true and other adjustments do indeed solve the problem. But with
ivy you only figure that stuff is even needed after you've been burned and
learned your lesson :-) My concern is for people who are just trying to
learn and use ivy and don't understand all the weird nooks and crannies. It
should behave reasonably for them... and (my opinion only of course) the
current behavior is not reasonable.
I suppose this problem could also be addressed with a big fat warning
somewhere in the documentation.
-Archie
--
Archie L. Cobbs
Re: Please vote: changing the default conflict manager
Posted by Mitch Gitman <mg...@gmail.com>.
Fortunately, we're not arguing here whether there should be a
"latest-compatible" strategy. It's already there.
Frankly, I'm very happy that "latest-revision" is the default. I like it
when a framework or component does the "dumb" or literal thing rather than
the "smart" or magical thing. If you're being undisciplined about how you
manage your dependencies, then I appreciate it that Ivy isn't automatically
trying to think things through for you and bail you out.
Also, I bet there are very few people out there who even have a full grasp
of what "latest-compatible" does under various circumstances. How many of
you could explain that strategy in a few sentences? I'd hate to see the
default be something that people scarcely even understand.
Archie, isn't the example you give a classic case of why there's
force="true"? And BTW, while I like that dependencies have a force option, I
chafe at using it. That's an indication to me that I don't have a full
handle on my repository's dependency graphs.
Preemptive apologies if I'm not able to follow up further on this thread.
On Thu, Sep 23, 2010 at 8:03 AM, Archie Cobbs <ar...@dellroad.org> wrote:
> In my opinion, the default behavior of ivy is very non-intuitive and
> violates POLA <
> http://en.wikipedia.org/wiki/Principle_of_least_astonishment>
> .
>
> I'm referring specifically to the default conflict manager being
> "latest-revision" instead of "latest-compatible".
>
> For a concrete example of what this means, suppose we have modules A, X and
> Y with these dependencies:
>
> A:
>
> <dependency name="X" rev="3.0"/>
> <dependency name="Y" rev="1.0"/>
>
> X:
>
> <dependency name="Y" rev="[1.0,)"/>
>
> Y:
>
> No dependencies
>
> 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.
>
> 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.)?
>
> Thanks,
> -Archie
>
> --
> Archie L. Cobbs
>
Re: Please vote: changing the default conflict manager
Posted by Carl Myers <cm...@palantir.com>.
What I think it *should* do is:
Resolve all dependencies, choosing the latest versions which cause no
conflicts for the entire set of transitive dependencies. I.e. the same
thing a strict resolve does, but if a conflict would have happened,
instead try the next newest version, and so on, until a compatible set
of versions are found.
One can imagine there are a lot of edge cases and implementation details
in this, the description is just from a user perspective, what the user
sees. If it doesn't work like this, I would be very interested in how
it does work, because this is my understanding of what it does, having
never actually read the code (yet).
-Carl
On 09/24/2010 07:54 AM, Archie Cobbs wrote:
> On Fri, Sep 24, 2010 at 9:32 AM, Mitch Gitman<mg...@gmail.com> wrote:
>
>> But Archie, can you or anyone else articulate in your own words the rules
>> of
>> latest-compatible? The current brief description in the documentation can
>> be
>> interpreted to mean anything. I would find it troubling if the maintainers
>> of an open-source framework are moving to a different default behavior, and
>> no one can put in plain English what that default behavior does.
>>
>
> I agree with that and would also like to understand the algorithm that
> latest-compatible uses before we decide to inflict it on everyone.
>
> Hopefully someone will explain it to us, otherwise I guess I'll have to do
> some code diving... :-)
>
> -Archie
>
--
Carl Myers
Palantir Technologies | Internal Tools Software Engineer
cmyers@palantir.com
Re: Please vote: changing the default conflict manager
Posted by Archie Cobbs <ar...@dellroad.org>.
On Fri, Sep 24, 2010 at 9:32 AM, Mitch Gitman <mg...@gmail.com> wrote:
> But Archie, can you or anyone else articulate in your own words the rules
> of
> latest-compatible? The current brief description in the documentation can
> be
> interpreted to mean anything. I would find it troubling if the maintainers
> of an open-source framework are moving to a different default behavior, and
> no one can put in plain English what that default behavior does.
>
I agree with that and would also like to understand the algorithm that
latest-compatible uses before we decide to inflict it on everyone.
Hopefully someone will explain it to us, otherwise I guess I'll have to do
some code diving... :-)
-Archie
--
Archie L. Cobbs
Re: Please vote: changing the default conflict manager
Posted by Archie Cobbs <ar...@dellroad.org>.
On Fri, Sep 24, 2010 at 9:32 AM, Mitch Gitman <mg...@gmail.com> wrote:
> But Archie, can you or anyone else articulate in your own words the rules
> of
> latest-compatible? The current brief description in the documentation can
> be
> interpreted to mean anything. I would find it troubling if the maintainers
> of an open-source framework are moving to a different default behavior, and
> no one can put in plain English what that default behavior does.
>
I have looked at the code but not thoroughly analyzed it. According to the
comments, it chooses the latest revision for each module that does not
violate some dependency.
However, I've already found one
bug<https://issues.apache.org/jira/browse/IVY-1233>(an infinite loop)
and so don't trust this code yet.
-Archie
--
Archie L. Cobbs
Re: Please vote: changing the default conflict manager
Posted by Mitch Gitman <mg...@gmail.com>.
Well, I'm kinda shifting from "opposed" to "open to it." The more I think
about it, the more I can see that Archie's use case isn't a case of Ivy
being overly helpful.
But Archie, can you or anyone else articulate in your own words the rules of
latest-compatible? The current brief description in the documentation can be
interpreted to mean anything. I would find it troubling if the maintainers
of an open-source framework are moving to a different default behavior, and
no one can put in plain English what that default behavior does.
On Fri, Sep 24, 2010 at 7:13 AM, Archie Cobbs <ar...@dellroad.org> wrote:
>
> 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.
>
>
Re: Please vote: changing the default conflict manager
Posted by Archie Cobbs <ar...@dellroad.org>.
On Thu, Sep 23, 2010 at 11:17 AM, Niklas Matthies <ml...@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
Re: Please vote: changing the default conflict manager
Posted by Niklas Matthies <ml...@nmhq.net>.
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