On 31 Jul 2011, at 13:15, Mark Struberg wrote: > 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.
FYI, those are the two classic provider vs consumer scenarios: http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
