maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <herve.bout...@free.fr>
Subject Re: Version ranges not working
Date Sat, 29 Sep 2012 02:26:31 GMT
"Anything else than pure numbers is a candidate to be broken somehow."
yes

Maven defines some qualifiers: see [1] for exact list (notice the synonyms, even 
for the release, that can be "ga" or "final")
I chose the qualifiers from what I could see that didn't have multiple 
interpretations: yes, MR is not a good candidate

Even the "a" and "b" qualifiers, which are actually synonyms for "alpha" and 
"beta", are sometimes used for maintenance release: well known example is 
javax.transaction 1.0.1B which is not a beta but maintenance release
But the choice was to ignore such exceptions and support "a" and "b" for alpha 
and beta shortcuts

Regards,

Hervé

[1] 
http://maven.apache.org/ref/3.0.4/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html

Le vendredi 28 septembre 2012 09:09:19 Mark Struberg a écrit :
> Sad but true.
> 
> An example:
> 
> There are projects which use "1.0-MR1" as "Milestone Release"
> 
> which gets released _before_ 1.0 final.
> 
> And there are other projects which use "1.0-MR1" as "Maintenance Release"
> 
> which obviously gets released _after_ 1.0 final.
> 
> Anything else than pure numbers is a candidate to be broken somehow.
> 
> 
> LieGrue,
> strub
> 
> ----- Original Message -----
> 
> > From: Stephen Connolly <stephen.alan.connolly@gmail.com>
> > To: Maven Users List <users@maven.apache.org>
> > Cc:
> > Sent: Friday, September 28, 2012 1:03 AM
> > Subject: Re: Version ranges not working
> > 
> > My experience with versions-maven-plugin would show different, but each to
> > their own
> > 
> > On 27 September 2012 23:56, Paul French <paul.french@kirona.com> 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 <paul.french@kirona.com>
> > 
> > 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
> > 
> > <paul.french@kirona.com> 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
> > 
> > <jpl@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<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.o
> > rg/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<users-unsubscribe@maven.apache.org>
> > 
> >>>>>>>>>>  For additional commands, e-mail:
> > users-help@maven.apache.org
> > 
> >>>>>>>>>>  
> > 
> > ------------------------------******--------------------------**
> > 
> >>>>>>>>>>  --**
> >>>>>>>>>  
> >>>>>>>>>  --**
> >>>>>>>>> 
> >>>>>>>>>   ---------
> >>>>>>>>> 
> >>>>>>>>  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<users-unsubscribe@maven.apache.org>
> > 
> >>>>>>>>  For additional commands, e-mail:
> > users-help@maven.apache.org
> > 
> >>>>>>>>  
> > 
> > ------------------------------******--------------------------**
> > 
> >>>>>>>>  --**
> >>>>>>>  
> >>>>>>>  --**---------
> > 
> >>>>>>>  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<users-unsubscribe@maven.apache.org>
> > 
> >>>>>>>  For additional commands, e-mail:
> > users-help@maven.apache.org
> > 
> >>>>>>>  
> > 
> > ------------------------------******--------------------------**
> > 
> >>>>>>>  --**
> >>>>>>  
> >>>>>>  --**---------
> > 
> >>>>>>  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<users-unsubscribe@maven.apache.org>
> > 
> >>>>>>  For additional commands, e-mail:
> > users-help@maven.apache.org
> > 
> >>>>>>  
> > 
> > ------------------------------****----------------------------**
> > 
> >>>>  --**---------
> > 
> >>>>  To unsubscribe, e-mail:
> > users-unsubscribe@maven.**apac**he.org<http://apache.org>
> > 
> > <users-unsubscribe@**maven.apache.org<users-unsubscribe@maven.apache.org>
> > 
> >>>>  For additional commands, e-mail: users-help@maven.apache.org
> >>  
> >>  ------------------------------**------------------------------**--------
> >>  -
> > 
> >>  To unsubscribe, e-mail:
> > users-unsubscribe@maven.**apache.org<users-unsubscribe@maven.apache.org>
> > 
> >>  For additional commands, e-mail: users-help@maven.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message