The use case that we originally came with in our discussions revolved around version ranges, and the fact that a version reference of "2.5.4" doesn't actually mean " give me 2.5.4" but rather "I would like 2.5.4, but meh, use something higher if you need to".
In the case were you have artifacts using say [1.0.0,2.0.0) and [1.5.0,3.0.0) as their ranges, maven will favor the highests higher bound, so if 1.5.1, 1.6.0, 2.0.1, and 2.5.0 are available, maven will choose 1.6.0 to compile against. What we were discussing was that ideally you'd to compile against the lowest lower bound ( 1.5.1 ), this way you'd get fail fast on any changed APIs that you inadvertently started to use, alerting you to the fact that you need to increment the lower bound of your range. If you require bug fixes in a newer release which is triggering your tests to fail, then you should also be incrementing the lower bound. The whole purpose of this flow is to drive you to releasing often, and working off binary dependencies rather than long standing -SNAPSHOTs. This flow would seem to work best for places who are releasing artifacts every 2-3 days, and working in a continuous delivery style process - it probably wouldn't work for Apache projects which often seem to favor long drawn out cycles ( I recall a thread awhile ago about not wanting to release a plugin cause it only had one bug fix in it ). Having read the other comments I realize my initial idea is a little crazy, and as Jason pointed out in the first response, probably more trouble than its worth. Mark On 31/07/2011, at 9:41 PM, Hervé BOUTEMY wrote: > Do you have practical examples that either are not supported, or the actual > ordering is the contrary than you expected?
