The problem I see with version ranges, is you start loosing control. I guess the vital part to make the use of version ranges work (at all) is that every developer has to follow the rule
major.minor.patch... So far, we have been very loose with versions - Someone changes 5 lines in the code, makes a new (patch) version, someone else changes another 7 lines, makes another (patch) version, and so on - we keep on "patching" the jar - 1.3.57 - I wonder when we will hit a hundred or a thousand! ;-) So I guess if EVERY developer would only use the "patch section" if it was really just a minor patch that will not influence anything really, but would use the minor or major section for all other changes, ranges might work without breaking other ppls builds - but this mechanismus counts on this very ability, which is hard to maintain, especially with new developers joining the team. When you have strict versions everyone has to change to a new version deliberately. About the thing with version numbers as property values in the parent pom - I am still not sure this is the best way, especially not with project that are not really shared by others, but this is the easiest way to update the dependency management section - otherwise, when someone changes the version of a submodule, one has to change this version, as well as the version in dep. mgmt. Hmmmm, this is really hard to swallow, I can't really find THE one and only solution of how to solve this dilemma - well, maybe I am still missing something? Peter
