H All,

If I understood well, dependency concept is based on something like:
<ivy-module version="1.0">
    <info organisation="jayasoft" module="hello-ivy" />
        <dependency org="apache" name="commons-lang" rev="2.0" />

So, a given version of a father depends on a given version of a given son.

As it is, and if I want to support commons-lang_2.1, I will have to deliver a new hello-ivy_1.1, even if nothing change in the hello-ivy code. Yes? No?

If the revision number is removed from the constraint, Ivy would consider than all commons-lang revisions are allowed (including all future ones). Yes? No?

Now, let's assume I would like to be more explicit about what has been really tested. For example, let's assume I delivered hello-ivy_1.1, 1.2 and 1.3, but tested only hello-ivy_1.1 with commons-lang_2.0 (the only existing at this time), then hello-ivy_1.2 with commons-lang_2.0 and 2.1, then hello-ivy_1.3 with commons-lang_3.0. Maybe hello-ivy_1.3 works with commons-lang_2.0 as well, but I never tested it. If some end-user requests it, I could perform all 1.3/3.0 tests then assert it as a valid (or invalid) combination .. without modifying in any manner all these delivered objects.

In other words, I would like to manage two type of information: a) a stable dependency from a versionned object to a non-versionned one, and b) an external and maybe increasing list of valid (or invalid) combinations.

Is there something in Ivy to manage such issue?