>With your mode the end user writes in his pom "i want v1" and with your >mechanism you do resolve v2 which doesn't have to be backward compat so >there is no reason it works (and in practise it wouldn't with a lot of
This still does not look like an example to me. Please explain how exactly Maven would resolve commons-compress to 2.0 with my proposal implemented assuming 2.0 is not backward compatible. What which exact piece of metadata (in which exact pom) would trick Maven to bump commons-compress to 2.0? (assuming you mean 2.0 being incompatible with 1.0) Hint: if commons-compress **vendor** plans for dropping backward compatibility, they would refrain from adding <dependencyManagement>commons-compress:2.0.0 when releasing 2.0 Vladimir
