yes, please share experience about ranges: when it is useful, how, and so on
we really need to write this Guide to using version ranges
https://jira.codehaus.org/browse/MNG-1368
so we stop telling ranges are a bad practice but tell what they are useful
for
Regards,
Hervé
Le samedi 29
Le lundi 1 octobre 2012 02:31:44 Jesse Long a écrit :
I have created a ticket - http://jira.codehaus.org/browse/MNG-5353
thank you
I changed it from Bug to Wish: no, nobody ever asked for such a behaviour,
it's really a new idea AFAIK
which BTW seems a good enhancement IMHO
now we need to check
It is clear version ranges are used by some people and they do find them
useful including me. You cannot predict how and in what circumstances
specific features of maven will be used by the many people out there,
good or bad in your opinion.
I still would prefer making version range
Users List users@maven.apache.org
Cc:
Sent: Saturday, September 29, 2012 5:06 AM
Subject: Re: Version ranges not working
yes, https://jira.codehaus.org/browse/MNG-3092 is still here
I'm not comfortable with the idea of excluding SNAPSHOT from ranges:
if we
do
so, it's not a *range
On Sun, Sep 30, 2012 at 12:28 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
I have other thoughts but my 2.75 yr old son now is demanding to play
racing cars on my phone, so I need to hit send on this mail now ;-)
I love it when priorities rear their ugly head. :-) Trust me
And while you're at it, please take care that the absence of a
versionRange is supported.
On Thu, Sep 27, 2012 at 11:19 PM, 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
Read what I wrote:
If you are making an artifact that is not upward compatible, you need to
prevent people from thinking that they can just up the version number in
their GAV and they will get a better version with bugs fixed.
You are in fact giving them a new artifact that will not only NOT
30, 2012 7:08 PM
Subject: Re: Version ranges not working
Read what I wrote:
If you are making an artifact that is not upward compatible, you need to
prevent people from thinking that they can just up the version number in
their GAV and they will get a better version with bugs fixed.
You
specification and switch (with CLI or IDE)
LieGrue,
strub
- Original Message -
From: Hervé BOUTEMY herve.bout...@free.fr
To: Maven Users List users@maven.apache.org
Cc:
Sent: Saturday, September 29, 2012 5:06 AM
Subject: Re: Version ranges not working
yes, https://jira.codehaus.org/browse
I think that Ron has hit the nail on the head here, and what he says
has become best practice, via many bruises, in the open source
community.
Maven has a fundamental version model. That model is does not cover
all possible real-world situations, as per JvZ's email and many
others. In particular,
On 29/09/2012 05:29, Hervé BOUTEMY wrote:
Le vendredi 28 septembre 2012 09:52:50 Jesse Long a écrit :
My point is really about exclusive upper bounds.
ok, now I'm starting to see the precise idea and believe it can avoid breaking
subtle logic
[1.7,1.8) could exclude anything starting with 1.8:
Regarding documentation, Maven generates a dependencies report, from the
pom.xml, which the user can read.
Regarding changing the artifactId for incompatibility, if you declare
that you use semantic version number, then the user can tell that there
is incompatibility by noticing that the
On 30/09/2012 9:11 PM, Jesse Long wrote:
Regarding documentation, Maven generates a dependencies report, from
the pom.xml, which the user can read.
Regarding changing the artifactId for incompatibility, if you declare
that you use semantic version number, then the user can tell that
there is
: Version ranges not working
yes, https://jira.codehaus.org/browse/MNG-3092 is still here
I'm not comfortable with the idea of excluding SNAPSHOT from ranges: if we
do
so, it's not a *range* any more but a range + a filter
(1.7.1-SNAPSHOT is in [1.7,1.8] range,in plain english)
and actual
To: Maven Users List users@maven.apache.org
Cc:
Sent: Saturday, September 29, 2012 5:06 AM
Subject: Re: Version ranges not working
yes, https://jira.codehaus.org/browse/MNG-3092 is still here
I'm not comfortable with the idea of excluding SNAPSHOT from ranges: if we
do
so, it's
: Saturday, September 29, 2012 5:06 AM
Subject: Re: Version ranges not working
yes, https://jira.codehaus.org/browse/MNG-3092 is still here
I'm not comfortable with the idea of excluding SNAPSHOT from ranges:
if we
do
so, it's not a *range* any more but a range + a filter
(1.7.1
Cc:
Sent: Saturday, September 29, 2012 5:06 AM
Subject: Re: Version ranges not working
yes, https://jira.codehaus.org/browse/MNG-3092 is still here
I'm not comfortable with the idea of excluding SNAPSHOT from ranges:
if we
do
so, it's not a *range* any more
: Hervé BOUTEMY herve.bout...@free.fr
To: Maven Users List users@maven.apache.org
Cc:
Sent: Saturday, September 29, 2012 5:06 AM
Subject: Re: Version ranges not working
yes, https://jira.codehaus.org/browse/MNG-3092 is still here
I'm not comfortable with the idea of excluding SNAPSHOT from
Wait,
You're suggesting we starting encoding VERSION NUMBERING into the artefact NAME
now? Isn't that just as bad, if not worse than the abuse of classifiers we
already see out there?
We have the exact same issue being discussed here, and also as mentioned by
others use OSGi. One of the key
This idea would require a POM change, but similar to repository definitions
having the option of declaring release or snapshot's being enabled, maybe
something similar could be provided for dependencies.
Or, with modifying the POM itself, we could extend the capability of the
classifier
+1 - we've mentioned this on the IA podcast a few times in the past - compile
against the lower bound, run against the upper bound.
How to express that however
On 30/09/2012, at 5:31 AM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:
In general at build time you want the lowest
I agree with Richard, as they exist now in maven version ranges can be used
very effectively. I'm happy to post example projects if you want to know
how to do it.
If you want 'repeatability' then ranges might not be for you but if you
want determinism and releasability then ranges are for you.
I - almost - disagree completely, I've successfully used ranges on seven
separate commercial projects. A mix of sizes from corporate to startup.
If you care at all about agility being explicit everyone is very
cumbersome, the fundamental aspect is determinism - meaning that its
obvious WHY it
For a practical solution...
I just stopped using 0's in versions.. maven interprets 1.8 as 1.8.0
then [1.7,1.8) will never match 1.8.1-SNAPSHOT
invariably you don't actually want a third parties release to affect you
build because what they consider and breaking change might not be for you
The composite pattern also makes exclusion very easy.
On Sep 30, 2012 3:35 PM, Michael McCallum mich...@stickycode.net wrote:
I - almost - disagree completely, I've successfully used ranges on seven
separate commercial projects. A mix of sizes from corporate to startup.
If you care at all
Without version ranges, how do I write a library that works with SLF4J
version 1.5.*, but does not work with SLF4J 1.6.*?
Do I depend on, say, version 1.5.11? Then when a user depends on my
library, and on slf4j-api directly, specifying slf4j-api version 1.6.0
in his pom, Maven will link in
My point is really about exclusive upper bounds.
I expect that [1.7,1.8] should contains 1.7.0 and above (no snapshots
and prerelease for 1.7.0) and 1.8.* release versions. Having said that,
I dont really care too much about this use case and have not thought
much about it. I have thought
to be broken somehow.
LieGrue,
strub
- Original Message -
From: Stephen Connolly stephen.alan.conno...@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
On 28/09/2012 3:17 AM, Jesse Long wrote:
Without version ranges, how do I write a library that works with SLF4J
version 1.5.*, but does not work with SLF4J 1.6.*?
Do I depend on, say, version 1.5.11? Then when a user depends on my
library, and on slf4j-api directly, specifying slf4j-api
I find this topic interesting for a couple of reasons. I was one of the
original posters of this topic and created some of the relevant JIRA issues
regarding it.
However one of the problems is that since this issue was never fixed...and
sadly seems never will be...we had to abandon the use of
On 28/09/2012 14:42, Ron Wheeler wrote:
On 28/09/2012 3:17 AM, Jesse Long wrote:
Without version ranges, how do I write a library that works with
SLF4J version 1.5.*, but does not work with SLF4J 1.6.*?
Do I depend on, say, version 1.5.11? Then when a user depends on my
library, and on
On 28 Sep 2012, at 4:13 PM, Jesse Long j...@unknown.za.net wrote:
My library does clearly document the versions of slf4j it depends on - as a
version range in the pom.xml file. How else?
Never mind slf4j for the time being, this affects all libraries.
Please see http://semver.org/
The
On 28/09/2012 10:31 AM, Graham Leggett wrote:
On 28 Sep 2012, at 4:13 PM, Jesse Long j...@unknown.za.net wrote:
My library does clearly document the versions of slf4j it depends on - as a
version range in the pom.xml file. How else?
If you are selling or distributing your product, it should
-
From: Stephen Connolly stephen.alan.conno...@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
yes, https://jira.codehaus.org/browse/MNG-3092 is still here
I'm not comfortable with the idea of excluding SNAPSHOT from ranges: if we do
so, it's not a *range* any more but a range + a filter
(1.7.1-SNAPSHOT is in [1.7,1.8] range,in plain english)
and actual discussion helps me dig into other
Le vendredi 28 septembre 2012 09:52:50 Jesse Long a écrit :
My point is really about exclusive upper bounds.
ok, now I'm starting to see the precise idea and believe it can avoid breaking
subtle logic
[1.7,1.8) could exclude anything starting with 1.8: betas, alphas, alphas-
alphas, snapshots
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
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
+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
Why not use
[1.7.0,1.7.99]
Just remember this when the project reaches revision 100 :-)
On 27-09-12 15:41, Jesse Long 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
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-alpha1.8-beta-1.8-rc1.8-SNAPSHOT1.8, it's pure math
IMHO, anything that doesn't conform mathematical
Le jeudi 27 septembre 2012 15:41:25 Jesse Long a écrit :
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
thanks for the report
I updated the link, should be visible in the page
Okay I see the problem.
How about allowing a user to plugin a Version class that implements
Comparator
class MavenVersion implements ComparableMavenVersion
{
public int compareTo(MavenVersion o)
{
// your implementation
}
}
Then we can all do whatever we need.
On
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
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
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
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
My experience with versions-maven-plugin would show different, but each to
their own
On 27 September 2012 23:56, Paul French paul.fre...@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
+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
+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
yes and no, depends
We have a lot of developers and a lot of OSGi bundles. The public API of
each bundle is specified in the manifest. We use API analysis to compare
the latest code of the artifact with the last released version of that
artifact. So the version of the updated bundle is
51 matches
Mail list logo
