+1
On 27/09/2012 7:20 PM, Baptiste MATHUS wrote:
+1.
Version ranges are basically just a bad practice in my experience. I mostly
don't see any interest apart from being able to see a normally passing
build suddenly going rogue because you somehow had a dependency update
somewhere in the dependency tree. (I wrote something similar in that
comment
http://www.sonatype.com/people/2012/08/download-it-all-at-once-a-maven-idea/#comment-635524577
)
So, please, Maven users, don't use them. It's like having scripts inside
your pom.xml, it might seem sexy and powerful, but it's dangerous.
Nail down a version, and upgrade explicitly when you need to and/or are
ready to. You'll be very happy that way and your build'll stay green.
Cheers
2012/9/28 Stephen Connolly <stephen.alan.conno...@gmail.com>
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.fre...@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.fre...@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 <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<
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.**apache.org <http://maven.apache.org><
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-unsubscribe@maven.**apac**he.org<
http://apache.org>
<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-unsubscribe@maven.**apac**he.org<
http://apache.org>
<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-unsubscribe@maven.**apac**he.org<
http://apache.org>
<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-unsubscribe@maven.**apache.org<
users-unsubscr...@maven.apache.org>
For additional commands, e-mail: users-h...@maven.apache.org
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
nbsp;!
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
