I understand that many people get caught But what do you expect from [1.7,1.8]? And [1.7,1.8-beta)?
The actual semantic is pure mathematical range, including or excluding an extreme since 1.8-alpha<1.8-beta-<1.8-rc<1.8-SNAPSHOT<1.8, it's pure math IMHO, anything that doesn't conform mathematical range will have some unexpected behaviour sometime Yes, people need to learn that they usually want [1.7,1.8-alpha-SNAPSHOT) if they want to be precise. Or approximations: [1.7,1.8-a), [1.7,1.7.999] Or we need to create another notation and define its semantics precisely Regards, Hervé Le jeudi 27 septembre 2012 20:46:08 Paul French a écrit : > +1 > > I agree with Jesse. > > A version range like [1.7,1.8) should exclude any artifact that starts > with 1.8 > > Then maven (or aether) would respect semantic versioning rules. > > We use version ranges/semantic versioning and API analysis to ensure our > artifacts are versioned correctly. Sometimes we get caught out by what > Jesse outlined below. > > On 27/09/2012 15:51, Stephen Connolly wrote: > > On 27 September 2012 14:41, Jesse Long <j...@unknown.za.net> wrote: > >> Dear Maven Community, > >> > >> I am writing to beg you to fix the problems with the version ranges in > >> Maven 3.0.5, specifically regarding the defining compatible version > >> ranges. > >> > >> I am using Maven 3.0.4. I have a simple project that depends on > >> org.slf4j:slf4j-api version 1.5.*. I define my compatibility range as > >> [1.5.0,1.6.0), but this links slf4j-api version 1.6.0-RC0. If I define > >> the > >> version range as [1.5.0,1.6.0-SNAPSHOT) I still get slf4j-api version > >> 1.6.0-RC0 linked in. I then tried [1.5.0,1.6.0-RC0), but then slf4j-api > >> version 1.6.0-alpha2 is linked in. > >> > >> Eventually, I discover that if I ask for [1.5.0,1.6.0-alpha), then the > >> correct version, 1.5.11, is linked in. But if version 1.6.0-aa7 was > >> released it would probably break again. > >> > >> This is all too counter-intuitive. The current version of SLF4J is 1.7.1. > >> If my project was to be built against it, knowing that there is a > >> likelihood of an incompatible change being introduced in 1.8.0 (SLF4J > >> does > >> not adhere to SemVer), I would like to define my version range for > >> slf4j-api as [1.7.0,1.8.0). I > > > > I think you do [1.7.0,1.8.0-!) > > > > but that might just include 1.8.0-SNAPSHOT > > > >> have no way of knowing before the time what type of -RC0, -alpha2 > >> qualified releases will be made for 1.8.0, so I can only exclude 1.8.0. > >> > >> However, when 1.8.0-alpha2 is released with incompatible changes, my > >> build > >> will immediately be broken. > >> > >> I could depend on version 1.5.11 directly, without using a version range, > >> but Maven considers this a soft version dependency and will ignore it as > >> needed. > >> > >> It is apparent that there is no reliable way to define a compatibility > >> range in Maven. I feel that this should be a major concern to all Maven > >> users and developers. > >> > >> It would be a shame for all the effort made by the Maven community to > >> make > >> software builds stable and reproducible to be undermined by consistent, > >> predictable breakage described above. > >> > >> I have read in mailing list archives that the suggested way of excluding > >> all 1.8.0 pre-release version is to define an exclusive upper bound as > >> 1.8.0-SNAPSHOT - like [1.7.0,1.8.0-SNAPSHOT). As demonstrated above with > >> 1.6.0-RC0, this does not work. Also, it makes no sense at all for a user > >> to > >> wish to include 1.8.0-SNAPSHOT and not 1.8.0. > >> > >> My proposal is that the qualifier is ignored when comparing a version to > >> the version number declared in an exclusive upper bound. ie. 1.6.0-xyz > >> should be considered equal to 1.6.0 in [1.5.0,1.6.0), and therefore > >> considered to fall outside of the version range. Importantly, it should > >> only be for the special case of comparing to the version number in an > >> exclusive upper bound. > >> > >> If the powers that be see fit, an exception could be made for service > >> pack > >> qualifiers, which according to one web page on Maven version ordering I > >> read, should be sorted after the release, although I would prefer to see > >> Maven more closely aligned to SemVer, where all qualified version numbers > >> are considered pre-release versions. I consider 1.7.2 a better version > >> number than 1.7.1-sp1. > >> > >> Ultimately, I would like to be able to make things as easy as possible > >> for > >> users depending on a library that adheres to SemVer, to define a > >> compatibility range like: [1.4.0,2.0.0). I see no reason why it should > >> not > >> be as easy as that. > >> > >> Please consider fixing this soon. > >> > >> I have not logged a Jira issue, as I cannot log into CodeHaus Jira. The > >> signup link on this page displays an error: > >> http://maven.apache.org/users/ > >> **getting-help.html <http://maven.apache.org/users/getting-help.html> > >> > >> Jira issue MNG-3092, reported over 5 years ago, is related to this issue, > >> but the initial report is for a similar issue, not this issue. The issue > >> I > >> describe above is reported and discussed in the comments for MNG-3092 > >> though. > >> > >> Thanks, > >> Jesse > >> > >> ------------------------------**------------------------------**--------- > >> To unsubscribe, e-mail: > >> users-unsubscribe@maven.**apache.org<users-unsubscr...@maven.apache.org> > >> For additional commands, e-mail: users-h...@maven.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
