My experience with versions-maven-plugin would show different, but each to their own
On 27 September 2012 23:56, Paul French <[email protected]> wrote: > I have to disagree. Version ranges are very useful to us especially with > artifacts we control where we use semantic versioning and api analysis to > enforce this. > > Artifacts we don't control the versioning of e.g SLF4J we nail down the > version we use. > > Our product POM's can have 100's of version ranged artifacts > > If we could plugin a version range class into maven (maven would ship with > a version range class with the rules it uses now), at least I would then > have a choice to replace it with an implementation I'm happier with. > > Anyway it works for us as it is now, so I'm not going to lose any sleep > over it. > > Cheers > > > On 27/09/2012 23:36, Stephen Connolly wrote: > >> Well that is a recipe for disaster. rules only make sense within the scope >> of the artifacts they apply to. >> >> This is kind of why version ranges are next to useless from a practical >> PoV >> anyway >> >> On 27 September 2012 23:05, Paul French <[email protected]> wrote: >> >> I would only want the same version rules applied to all artifacts, not on >>> a per artifact basis, that would be a nightmare! I understand that people >>> who produce artifacts have their own versioning rules. However we can >>> take >>> that into account in our version ranging. >>> >>> Usually for 3rd party artifacts we have a very narrow version range since >>> we cannot trust the producer of that artifact not to break their current >>> API in later versions unless they support semantic versioning. >>> >>> >>> On 27/09/2012 22:29, Stephen Connolly wrote: >>> >>> when is that class applied? >>>> >>>> each dependency would have its own comparator, as each dependency has >>>> its >>>> own versioning rules. >>>> >>>> and then don't start on epoch's (i.e. where the versioning rules change >>>> from under your feet mid sequence >>>> >>>> It's tempting... but dangerous... the closest I have come up with is the >>>> rulesets hack from versions-maven-plugin @ mojo... but even that has >>>> issues... hence why I haven't pushed it further. >>>> >>>> -Stephen >>>> >>>> On 27 September 2012 22:19, Paul French <[email protected]> wrote: >>>> >>>> Okay I see the problem. >>>> >>>>> How about allowing a user to plugin a Version class that implements >>>>> Comparator >>>>> >>>>> class MavenVersion implements Comparable<MavenVersion> >>>>> { >>>>> public int compareTo(MavenVersion o) >>>>> { >>>>> // your implementation >>>>> } >>>>> } >>>>> >>>>> Then we can all do whatever we need. >>>>> >>>>> >>>>> On 27/09/2012 21:40, Hervé BOUTEMY wrote: >>>>> >>>>> 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 <[email protected]> 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<http:/**/maven.apache.org/**users/** >>>>>>>>> getting-help.html<http://maven.apache.org/**users/getting-help.html> >>>>>>>>> > >>>>>>>>> <http:/**/maven.apache.org/**users/**getting-help.html<http://maven.apache.org/users/**getting-help.html> >>>>>>>>> <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.******apac**he.org <http://apache.org>< >>>>>>>>> users-unsubscribe@**maven.**ap**ache.org <http://apache.org> < >>>>>>>>> http://maven.apache.org>< >>>>>>>>> >>>>>>>>> users-unsubscribe@**maven.**apache.org <http://maven.apache.org>< >>>>>>>>> users-unsubscribe@**maven.apache.org<[email protected]> >>>>>>>>> > >>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>> >>>>>>>>> ------------------------------******--------------------------** >>>>>>>>> --** >>>>>>>>> >>>>>>>> --** >>>>>>>> >>>>>>>> --------- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.****apac**he.org< >>>>>>> http://apache.org**> >>>>>>> <users-unsubscribe@**maven.**apache.org <http://maven.apache.org>< >>>>>>> users-unsubscribe@**maven.apache.org<[email protected]> >>>>>>> > >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> ------------------------------******--------------------------** >>>>>>> --** >>>>>>> >>>>>> --**--------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.****apac**he.org< >>>>>> http://apache.org**> >>>>>> <users-unsubscribe@**maven.**apache.org <http://maven.apache.org>< >>>>>> users-unsubscribe@**maven.apache.org<[email protected]> >>>>>> > >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>>> ------------------------------******--------------------------** >>>>>> --** >>>>>> >>>>> --**--------- >>>>> To unsubscribe, e-mail: users-unsubscribe@maven.****apac**he.org< >>>>> http://apache.org**> >>>>> <users-unsubscribe@**maven.**apache.org <http://maven.apache.org>< >>>>> users-unsubscribe@**maven.apache.org<[email protected]> >>>>> > >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>>> >>>>> ------------------------------****----------------------------** >>> --**--------- >>> To unsubscribe, e-mail: >>> users-unsubscribe@maven.**apac**he.org<http://apache.org> >>> <users-unsubscribe@**maven.apache.org<[email protected]> >>> > >>> For additional commands, e-mail: [email protected] >>> >>> >>> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@maven.**apache.org<[email protected]> > For additional commands, e-mail: [email protected] > >
