If I understood well, dependency concept is based on something like:
<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
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)
Is there something in Ivy to manage such issue?