You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Paul Gier <pg...@redhat.com> on 2011/05/27 18:02:11 UTC
Handling of unrecognised version qualifiers
Maven 3 currently treats unrecognised version qualifiers as newer
releases than the GA release. For example:
1.0 is older than 1.0-xyz
It also looks like this was reversed at some point, since there is a
test case commented out on line 117 that expects the opposite behaviour
[1]. So is the current behaviour correct? Or does the commented test
case mean that this ordering will be reversed at some point in the future?
My personal preference is that we replace the commented test case with
one testing for the reverse order, so that we prevent this from changing
in the future. So all unrecognised qualifiers are treated as patch
releases, and considered newer than the GA release.
Thanks!
[1]http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/DefaultArtifactVersionTest.java?annotate=1084807
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Handling of unrecognised version qualifiers
Posted by Hervé BOUTEMY <he...@free.fr>.
Le vendredi 27 mai 2011, John Casey a écrit :
> Again, something like this should be formalized in our version spec.
Our version comparison spec is both the ComparableVersion javadoc [1] and the
proposal on the Wiki [2]
I just updated them both to be explicit about this change
Regards,
Hervé
[1] http://maven.apache.org/ref/3.0.3/maven-
artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html
[2] https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Handling of unrecognised version qualifiers
Posted by Hervé BOUTEMY <he...@free.fr>.
Le vendredi 27 mai 2011, John Casey a écrit :
> On 5/27/11 1:03 PM, Benson Margulies wrote:
> > This seems to me to call out for an 'extension point' that supplies an
> > object that implements a protocol for making version decisions.
>
> That would bring up the issue of how Maven switches between version
> schemes on the fly when resolving transitive dependencies...and, whether
> a given newcomer to the project could build it with a plain old vanilla
> version of Maven.
yes, and this decision has to be made dependency by dependency, not globally
for all dependencies of the current project
this version support was tracked in the Wiki [1]
When working on it, I totally abandonned the idea of having such an
extensible/configurable ordering: I doubt this would be understandable.
But if anybody thinks it can be done, I'll be glad to challenge the solution
:)
Regards,
Hervé
[1] https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Handling of unrecognised version qualifiers
Posted by John Casey <jd...@commonjava.org>.
On 5/27/11 1:03 PM, Benson Margulies wrote:
> This seems to me to call out for an 'extension point' that supplies an
> object that implements a protocol for making version decisions.
That would bring up the issue of how Maven switches between version
schemes on the fly when resolving transitive dependencies...and, whether
a given newcomer to the project could build it with a plain old vanilla
version of Maven.
>
> On Fri, May 27, 2011 at 12:31 PM, John Casey<jd...@commonjava.org> wrote:
>>
>>
>> On 5/27/11 12:02 PM, Paul Gier wrote:
>>>
>>> Maven 3 currently treats unrecognised version qualifiers as newer
>>> releases than the GA release. For example:
>>>
>>> 1.0 is older than 1.0-xyz
>>>
>>> It also looks like this was reversed at some point, since there is a
>>> test case commented out on line 117 that expects the opposite behaviour
>>> [1]. So is the current behaviour correct? Or does the commented test
>>> case mean that this ordering will be reversed at some point in the future?
>>>
>>> My personal preference is that we replace the commented test case with
>>> one testing for the reverse order, so that we prevent this from changing
>>> in the future. So all unrecognised qualifiers are treated as patch
>>> releases, and considered newer than the GA release.
>>
>> FWIW, I completely agree. We have a use case where existing artifacts need
>> to be rebuilt, in order to provide separate testing/signing/etc.
>>
>> I think we need to formalize methods for specifying versions that allow
>> proper sorting in two different scenarios:
>>
>> 1. rebuilds, which I think the current (accidental?) sorting of 1.0-myco-1
>> as more recent than 1.0 handles neatly. This should be formalized in the
>> version spec.
>>
>> 2. patched, pre-release builds, such as when a company has developed a patch
>> for a version of some project, but this patch hasn't been incorporated into
>> an official release yet. In this case, using something like 1.0-m1-myco
>> might signify that this is a patch/milestone build of 1.0 (so, pre-1.0)
>> created by 'myco'...and, sort as "older" than 1.0. Again, something like
>> this should be formalized in our version spec.
>>
>> Just my $0.02
>>
>>>
>>> Thanks!
>>>
>>>
>>> [1]http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/DefaultArtifactVersionTest.java?annotate=1084807
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> --
>> John Casey
>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>> Blog: http://www.johnofalltrades.name/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Handling of unrecognised version qualifiers
Posted by John Casey <jd...@commonjava.org>.
On 5/27/11 1:16 PM, Mark Struberg wrote:
> not sure if that would scale.
>
> One dependency is using CR as acronym for 'candidate release' another is using it for 'correctional release' or something.
>
> Since there is no fixed list, this would really be hard to impl.
> In fact it's mostly about sub-numbers (split with a '-').
There may not be a fixed list in absolute terms, but it's easy enough to
fit into mainstream use cases without much extra work.
In my case, I'm talking about
1.0-RC1 (release candidate)
.
1.0 (community release)
.
1.0-myco-1 (verification/signed REBUILD of community release; 1st
. independent rebuild of 1.0 codebase from 'myco')
.
1.0-myco-2 (patches to 1.0 community release; 2nd build of 1.0 codebase
. from 'myco')
.
1.1
I'm less concerned with making One Version Scheme to Rule Them All, and
more interested in defining a path for these use cases in our Maven-ish
version scheme, so if folks are interested in using the mainstream
version scheme, that scheme is enough to cope with real world
scenarios...regardless of whether some people don't like *how* it copes.
>
> LieGrue,
> strub
>
> --- On Fri, 5/27/11, Benson Margulies<bi...@gmail.com> wrote:
>
>> From: Benson Margulies<bi...@gmail.com>
>> Subject: Re: Handling of unrecognised version qualifiers
>> To: "Maven Developers List"<de...@maven.apache.org>
>> Date: Friday, May 27, 2011, 5:03 PM
>> This seems to me to call out for an
>> 'extension point' that supplies an
>> object that implements a protocol for making version
>> decisions.
>>
>> On Fri, May 27, 2011 at 12:31 PM, John Casey<jd...@commonjava.org>
>> wrote:
>>>
>>>
>>> On 5/27/11 12:02 PM, Paul Gier wrote:
>>>>
>>>> Maven 3 currently treats unrecognised version
>> qualifiers as newer
>>>> releases than the GA release. For example:
>>>>
>>>> 1.0 is older than 1.0-xyz
>>>>
>>>> It also looks like this was reversed at some
>> point, since there is a
>>>> test case commented out on line 117 that expects
>> the opposite behaviour
>>>> [1]. So is the current behaviour correct? Or
>> does the commented test
>>>> case mean that this ordering will be reversed at
>> some point in the future?
>>>>
>>>> My personal preference is that we replace the
>> commented test case with
>>>> one testing for the reverse order, so that we
>> prevent this from changing
>>>> in the future. So all unrecognised qualifiers
>> are treated as patch
>>>> releases, and considered newer than the GA
>> release.
>>>
>>> FWIW, I completely agree. We have a use case where
>> existing artifacts need
>>> to be rebuilt, in order to provide separate
>> testing/signing/etc.
>>>
>>> I think we need to formalize methods for specifying
>> versions that allow
>>> proper sorting in two different scenarios:
>>>
>>> 1. rebuilds, which I think the current (accidental?)
>> sorting of 1.0-myco-1
>>> as more recent than 1.0 handles neatly. This should be
>> formalized in the
>>> version spec.
>>>
>>> 2. patched, pre-release builds, such as when a company
>> has developed a patch
>>> for a version of some project, but this patch hasn't
>> been incorporated into
>>> an official release yet. In this case, using something
>> like 1.0-m1-myco
>>> might signify that this is a patch/milestone build of
>> 1.0 (so, pre-1.0)
>>> created by 'myco'...and, sort as "older" than 1.0.
>> Again, something like
>>> this should be formalized in our version spec.
>>>
>>> Just my $0.02
>>>
>>>>
>>>> Thanks!
>>>>
>>>>
>>>> [1]http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/DefaultArtifactVersionTest.java?annotate=1084807
>>>>
>>>>
>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> --
>>> John Casey
>>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>>> Blog: http://www.johnofalltrades.name/
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Handling of unrecognised version qualifiers
Posted by Mark Struberg <st...@yahoo.de>.
not sure if that would scale.
One dependency is using CR as acronym for 'candidate release' another is using it for 'correctional release' or something.
Since there is no fixed list, this would really be hard to impl.
In fact it's mostly about sub-numbers (split with a '-').
LieGrue,
strub
--- On Fri, 5/27/11, Benson Margulies <bi...@gmail.com> wrote:
> From: Benson Margulies <bi...@gmail.com>
> Subject: Re: Handling of unrecognised version qualifiers
> To: "Maven Developers List" <de...@maven.apache.org>
> Date: Friday, May 27, 2011, 5:03 PM
> This seems to me to call out for an
> 'extension point' that supplies an
> object that implements a protocol for making version
> decisions.
>
> On Fri, May 27, 2011 at 12:31 PM, John Casey <jd...@commonjava.org>
> wrote:
> >
> >
> > On 5/27/11 12:02 PM, Paul Gier wrote:
> >>
> >> Maven 3 currently treats unrecognised version
> qualifiers as newer
> >> releases than the GA release. For example:
> >>
> >> 1.0 is older than 1.0-xyz
> >>
> >> It also looks like this was reversed at some
> point, since there is a
> >> test case commented out on line 117 that expects
> the opposite behaviour
> >> [1]. So is the current behaviour correct? Or
> does the commented test
> >> case mean that this ordering will be reversed at
> some point in the future?
> >>
> >> My personal preference is that we replace the
> commented test case with
> >> one testing for the reverse order, so that we
> prevent this from changing
> >> in the future. So all unrecognised qualifiers
> are treated as patch
> >> releases, and considered newer than the GA
> release.
> >
> > FWIW, I completely agree. We have a use case where
> existing artifacts need
> > to be rebuilt, in order to provide separate
> testing/signing/etc.
> >
> > I think we need to formalize methods for specifying
> versions that allow
> > proper sorting in two different scenarios:
> >
> > 1. rebuilds, which I think the current (accidental?)
> sorting of 1.0-myco-1
> > as more recent than 1.0 handles neatly. This should be
> formalized in the
> > version spec.
> >
> > 2. patched, pre-release builds, such as when a company
> has developed a patch
> > for a version of some project, but this patch hasn't
> been incorporated into
> > an official release yet. In this case, using something
> like 1.0-m1-myco
> > might signify that this is a patch/milestone build of
> 1.0 (so, pre-1.0)
> > created by 'myco'...and, sort as "older" than 1.0.
> Again, something like
> > this should be formalized in our version spec.
> >
> > Just my $0.02
> >
> >>
> >> Thanks!
> >>
> >>
> >> [1]http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/DefaultArtifactVersionTest.java?annotate=1084807
> >>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >
> > --
> > John Casey
> > Developer, PMC Member - Apache Maven (http://maven.apache.org)
> > Blog: http://www.johnofalltrades.name/
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Handling of unrecognised version qualifiers
Posted by Benson Margulies <bi...@gmail.com>.
This seems to me to call out for an 'extension point' that supplies an
object that implements a protocol for making version decisions.
On Fri, May 27, 2011 at 12:31 PM, John Casey <jd...@commonjava.org> wrote:
>
>
> On 5/27/11 12:02 PM, Paul Gier wrote:
>>
>> Maven 3 currently treats unrecognised version qualifiers as newer
>> releases than the GA release. For example:
>>
>> 1.0 is older than 1.0-xyz
>>
>> It also looks like this was reversed at some point, since there is a
>> test case commented out on line 117 that expects the opposite behaviour
>> [1]. So is the current behaviour correct? Or does the commented test
>> case mean that this ordering will be reversed at some point in the future?
>>
>> My personal preference is that we replace the commented test case with
>> one testing for the reverse order, so that we prevent this from changing
>> in the future. So all unrecognised qualifiers are treated as patch
>> releases, and considered newer than the GA release.
>
> FWIW, I completely agree. We have a use case where existing artifacts need
> to be rebuilt, in order to provide separate testing/signing/etc.
>
> I think we need to formalize methods for specifying versions that allow
> proper sorting in two different scenarios:
>
> 1. rebuilds, which I think the current (accidental?) sorting of 1.0-myco-1
> as more recent than 1.0 handles neatly. This should be formalized in the
> version spec.
>
> 2. patched, pre-release builds, such as when a company has developed a patch
> for a version of some project, but this patch hasn't been incorporated into
> an official release yet. In this case, using something like 1.0-m1-myco
> might signify that this is a patch/milestone build of 1.0 (so, pre-1.0)
> created by 'myco'...and, sort as "older" than 1.0. Again, something like
> this should be formalized in our version spec.
>
> Just my $0.02
>
>>
>> Thanks!
>>
>>
>> [1]http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/DefaultArtifactVersionTest.java?annotate=1084807
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> John Casey
> Developer, PMC Member - Apache Maven (http://maven.apache.org)
> Blog: http://www.johnofalltrades.name/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Handling of unrecognised version qualifiers
Posted by Paul Gier <pg...@redhat.com>.
On 05/27/2011 11:44 AM, Mark Struberg wrote:
> It's about
>
> 1.0
> vs
> 1.0-RC (Release Candidate)
> vs
> 1.0-MR (Maintenance Release)
>
> right?
>
Yes. RC is recognized by Maven 3 as earlier than GA (or no qualifier).
MR is not recognized by Maven 3 and is assumed to be later than GA.
> I think one solution is in general equally good as the other since there is no generally working solution.
>
>
> Thus I'd also strongly +1 for re-establishing the old behaviour. Otherwise we'd break backward compatibility. Also note that this code was (is still?) duplicated a few times over the whole codebase - and also got 'cloned' in plugins.
>
> Maven3 is warning about non-pinned versions anyway, so it's really mostly about old mvn2 projects which would suddenly be broken in mvn3.
>
> LieGrue,
> strub
>
> --- On Fri, 5/27/11, John Casey <jd...@commonjava.org> wrote:
>
>> From: John Casey <jd...@commonjava.org>
>> Subject: Re: Handling of unrecognised version qualifiers
>> To: "Maven Developers List" <de...@maven.apache.org>
>> Date: Friday, May 27, 2011, 4:31 PM
>>
>>
>> On 5/27/11 12:02 PM, Paul Gier wrote:
>>> Maven 3 currently treats unrecognised version
>> qualifiers as newer
>>> releases than the GA release. For example:
>>>
>>> 1.0 is older than 1.0-xyz
>>>
>>> It also looks like this was reversed at some point,
>> since there is a
>>> test case commented out on line 117 that expects the
>> opposite behaviour
>>> [1]. So is the current behaviour correct?
>> Or does the commented test
>>> case mean that this ordering will be reversed at some
>> point in the future?
>>>
>>> My personal preference is that we replace the
>> commented test case with
>>> one testing for the reverse order, so that we prevent
>> this from changing
>>> in the future. So all unrecognised qualifiers
>> are treated as patch
>>> releases, and considered newer than the GA release.
>>
>> FWIW, I completely agree. We have a use case where existing
>> artifacts need to be rebuilt, in order to provide separate
>> testing/signing/etc.
>>
>> I think we need to formalize methods for specifying
>> versions that allow proper sorting in two different
>> scenarios:
>>
>> 1. rebuilds, which I think the current (accidental?)
>> sorting of 1.0-myco-1 as more recent than 1.0 handles
>> neatly. This should be formalized in the version spec.
>>
>> 2. patched, pre-release builds, such as when a company has
>> developed a patch for a version of some project, but this
>> patch hasn't been incorporated into an official release yet.
>> In this case, using something like 1.0-m1-myco might signify
>> that this is a patch/milestone build of 1.0 (so, pre-1.0)
>> created by 'myco'...and, sort as "older" than 1.0. Again,
>> something like this should be formalized in our version
>> spec.
>>
>> Just my $0.02
>>
>>>
>>> Thanks!
>>>
>>> [1]http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/DefaultArtifactVersionTest.java?annotate=1084807
>>>
>>>
>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> -- John Casey
>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>> Blog: http://www.johnofalltrades.name/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Handling of unrecognised version qualifiers
Posted by Mark Struberg <st...@yahoo.de>.
It's about
1.0
vs
1.0-RC (Release Candidate)
vs
1.0-MR (Maintenance Release)
right?
I think one solution is in general equally good as the other since there is no generally working solution.
Thus I'd also strongly +1 for re-establishing the old behaviour. Otherwise we'd break backward compatibility. Also note that this code was (is still?) duplicated a few times over the whole codebase - and also got 'cloned' in plugins.
Maven3 is warning about non-pinned versions anyway, so it's really mostly about old mvn2 projects which would suddenly be broken in mvn3.
LieGrue,
strub
--- On Fri, 5/27/11, John Casey <jd...@commonjava.org> wrote:
> From: John Casey <jd...@commonjava.org>
> Subject: Re: Handling of unrecognised version qualifiers
> To: "Maven Developers List" <de...@maven.apache.org>
> Date: Friday, May 27, 2011, 4:31 PM
>
>
> On 5/27/11 12:02 PM, Paul Gier wrote:
> > Maven 3 currently treats unrecognised version
> qualifiers as newer
> > releases than the GA release. For example:
> >
> > 1.0 is older than 1.0-xyz
> >
> > It also looks like this was reversed at some point,
> since there is a
> > test case commented out on line 117 that expects the
> opposite behaviour
> > [1]. So is the current behaviour correct?
> Or does the commented test
> > case mean that this ordering will be reversed at some
> point in the future?
> >
> > My personal preference is that we replace the
> commented test case with
> > one testing for the reverse order, so that we prevent
> this from changing
> > in the future. So all unrecognised qualifiers
> are treated as patch
> > releases, and considered newer than the GA release.
>
> FWIW, I completely agree. We have a use case where existing
> artifacts need to be rebuilt, in order to provide separate
> testing/signing/etc.
>
> I think we need to formalize methods for specifying
> versions that allow proper sorting in two different
> scenarios:
>
> 1. rebuilds, which I think the current (accidental?)
> sorting of 1.0-myco-1 as more recent than 1.0 handles
> neatly. This should be formalized in the version spec.
>
> 2. patched, pre-release builds, such as when a company has
> developed a patch for a version of some project, but this
> patch hasn't been incorporated into an official release yet.
> In this case, using something like 1.0-m1-myco might signify
> that this is a patch/milestone build of 1.0 (so, pre-1.0)
> created by 'myco'...and, sort as "older" than 1.0. Again,
> something like this should be formalized in our version
> spec.
>
> Just my $0.02
>
> >
> > Thanks!
> >
> > [1]http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/DefaultArtifactVersionTest.java?annotate=1084807
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> -- John Casey
> Developer, PMC Member - Apache Maven (http://maven.apache.org)
> Blog: http://www.johnofalltrades.name/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Handling of unrecognised version qualifiers
Posted by John Casey <jd...@commonjava.org>.
On 5/27/11 12:02 PM, Paul Gier wrote:
> Maven 3 currently treats unrecognised version qualifiers as newer
> releases than the GA release. For example:
>
> 1.0 is older than 1.0-xyz
>
> It also looks like this was reversed at some point, since there is a
> test case commented out on line 117 that expects the opposite behaviour
> [1]. So is the current behaviour correct? Or does the commented test
> case mean that this ordering will be reversed at some point in the future?
>
> My personal preference is that we replace the commented test case with
> one testing for the reverse order, so that we prevent this from changing
> in the future. So all unrecognised qualifiers are treated as patch
> releases, and considered newer than the GA release.
FWIW, I completely agree. We have a use case where existing artifacts
need to be rebuilt, in order to provide separate testing/signing/etc.
I think we need to formalize methods for specifying versions that allow
proper sorting in two different scenarios:
1. rebuilds, which I think the current (accidental?) sorting of
1.0-myco-1 as more recent than 1.0 handles neatly. This should be
formalized in the version spec.
2. patched, pre-release builds, such as when a company has developed a
patch for a version of some project, but this patch hasn't been
incorporated into an official release yet. In this case, using something
like 1.0-m1-myco might signify that this is a patch/milestone build of
1.0 (so, pre-1.0) created by 'myco'...and, sort as "older" than 1.0.
Again, something like this should be formalized in our version spec.
Just my $0.02
>
> Thanks!
>
> [1]http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/DefaultArtifactVersionTest.java?annotate=1084807
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.johnofalltrades.name/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Handling of unrecognised version qualifiers
Posted by Hervé BOUTEMY <he...@free.fr>.
Le mardi 7 juin 2011, Paul Gier a écrit :
> On 05/27/2011 11:02 AM, Paul Gier wrote:
> > Maven 3 currently treats unrecognised version qualifiers as newer
> > releases than the GA release. For example:
> >
> > 1.0 is older than 1.0-xyz
> >
> > It also looks like this was reversed at some point, since there is a
> > test case commented out on line 117 that expects the opposite behaviour
> > [1]. So is the current behaviour correct? Or does the commented test
> > case mean that this ordering will be reversed at some point in the
> > future?
> >
> > My personal preference is that we replace the commented test case with
> > one testing for the reverse order, so that we prevent this from changing
> > in the future. So all unrecognised qualifiers are treated as patch
> > releases, and considered newer than the GA release.
> >
> > Thanks!
> >
> > [1]http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-artifact/src/te
> > st/java/org/apache/maven/artifact/versioning/DefaultArtifactVersionTest.j
> > ava?annotate=1084807
>
> Based on this discussion, I add a couple of checks in the unit test to
> verify the current behaviour.
>
> http://jira.codehaus.org/browse/MNG-5114
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
in fact, this case was already covered by ComparableVersionTest, which is the
full version order test, written with a more generic approach.
I don't remember if I reverted this case by inadvertance or because I
discovered a subtle case that could not be handled, sorry.
Regards,
Hervé
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Handling of unrecognised version qualifiers
Posted by Paul Gier <pg...@redhat.com>.
On 05/27/2011 11:02 AM, Paul Gier wrote:
> Maven 3 currently treats unrecognised version qualifiers as newer
> releases than the GA release. For example:
>
> 1.0 is older than 1.0-xyz
>
> It also looks like this was reversed at some point, since there is a
> test case commented out on line 117 that expects the opposite behaviour
> [1]. So is the current behaviour correct? Or does the commented test
> case mean that this ordering will be reversed at some point in the future?
>
> My personal preference is that we replace the commented test case with
> one testing for the reverse order, so that we prevent this from changing
> in the future. So all unrecognised qualifiers are treated as patch
> releases, and considered newer than the GA release.
>
> Thanks!
>
> [1]http://svn.apache.org/viewvc/maven/maven-3/trunk/maven-artifact/src/test/java/org/apache/maven/artifact/versioning/DefaultArtifactVersionTest.java?annotate=1084807
Based on this discussion, I add a couple of checks in the unit test to
verify the current behaviour.
http://jira.codehaus.org/browse/MNG-5114
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org