Actually, it is not only in case of deleted revision that it might be useful to have a range of accepted values.
I might be wrong, but currently when you develop a library and you publish it, you can not specify the range of version that you support. I mean, you can do it in your source ivy.xml, but not in the ivy.xml you publish. For example, let say that ivy is a reusable module (just imagine ;-). Ivy has a dependency with ant. Ivy support [at least] 1.6 and 1.7. You can say that in the ivy source, but once it is published, it will be published with the 1.7 dependency only (or 1.6, I don't know). You have loosed some useful information for your user. And they are now forced to use 1.7. Even if some users might prefer to have only fixed version dependencies, some will prefer to offer more flexibility to their users and will prefer to publish version ranges. Is my understanding correct (I didn't tried a lot to play with version range) Note that there is certainly a lot of issue to consider: - Build reproducibility? - New attributes in the ivy.xml? - New parameters for the resolve and for the publish task? - What happen if a module publish ranges but its user prefer to have a fixed version? - How can a module provider be sure that he really supports all those versions? (See https://issues.apache.org/jira/browse/IVY-386) Gilles
