On Wed, 2008-12-03 at 23:38 -0700, Barrie Treloar wrote: > On Thu, Dec 4, 2008 at 11:06 AM, Ian Robertson <[EMAIL PROTECTED]> wrote: > > I would propose that the semantics change to "Of the overlapping ranges, > > the *lowest* soft requirement is the version to be used." Consequently, > > new releases of a project would not change builds of other projects > > depending on it (assuming that version numbers increase instead of decrease > > with each release). This would negatively impact those projects wanting to > > live on the "bleeding edge", but benefit projects wanting repeatable > > builds. In practice, range syntax does not appear to have gained much > > traction to date, so this change would hopefully not have substantial > > impact in terms of backwards incompatibility. Moreover, providing > > semantics which do not introduce instability might increase adoption of the > > syntax. > > I think the short answer is, if you want repeatable builds then don't > use range syntax. > By defining a range you are saying that everything that fits in this > range is a valid choice. > Even those in the future that have yet to be release, as long as they > fit in the range. > Given that these future versions dont exist they haven't been tested > so using a range can be dangerous. You raise a good point - open-ended version ranges leave one vulnerable to backwards-incompatible library upgrades. But the current strategy of taking the highest version introduces an additional element of instability to application that can appear from one day to the next without any change to an applications code base.
Unfortunately, without a notion of version ranges, managing versions becomes prohibitive in projects with large dependency graphs. If an application has several different transitive dependencies on a particular library, the application developer is forced to traverse the entire graph, examine all the dependencies, and choose the highest of them so that she is guaranteed not to hit NoClassDefFoundErrors or NoSuchMethodErrors at runtime. For projects with hundreds of transitive dependencies, this is error-prone at best. Version ranges allow each module to declare the minimum version it needs to run properly, and let maven do the work of finding a version acceptable to all modules in the dependency graph. > There is talk about a plugin (can't recall which) that can lock down > the version of plugins and also tell you if newer versions are > available, so you can selectively decide to upgrade. But I am not > sure if such a plugin exists yet. The versions-maven-plugin looks useful, but doesn't appear to address transitive dependencies which are never mentioned in an application's pom.xml. That's one of the main issues I'm trying to solve. CONFIDENTIALITY NOTICE: This message is intended only for the use and review of the individual or entity to which it is addressed and may contain information that is privileged and confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message solely to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify sender immediately by telephone or return email. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
