I thought about that too, and actually don't think that there is a general solution.
Two examples: * JDBC-4.1 Driver and DataSource interfaces in OpenJDK-1.7 got a new getParentLogger() method. To compile your own DataSource with java7 you need to implement this method. It is perfectly compatible to get executed on java5 and 6 too, so what you need is the latest version of the dependency (JDBC-4.1) while compiling your project. If you get invoked as a callback or similar, it's a good idea to implement the widest possible range. * The story turns around if you act as a client invoking other libs. If interfaces you use in your projects got extended with new methods in a new version, then this will obviously not work together with older lib versions once you made use of the new methods. In this case you should restrict yourself to the subset of methods available in all versions of the lib. Plus, there are lots of grey tones between those 2 scenarios. E.g. if some method parameter or config tag expresses version and capability... LieGrue, strub PS: you can at least check the backward compat of your own lib with the maven-clirr-plugin. --- On Sun, 7/31/11, Jason van Zyl <ja...@sonatype.com> wrote: > From: Jason van Zyl <ja...@sonatype.com> > Subject: Re: Pluggable Dependency Resolution > To: "Maven Developers List" <dev@maven.apache.org> > Date: Sunday, July 31, 2011, 11:58 AM > What if you could find another way to > check API compatibility, would you need this at all? > > On Jul 31, 2011, at 6:03 AM, Mark Derricutt wrote: > > > 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? > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
