maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: Handling of unrecognised version qualifiers
Date Fri, 27 May 2011 17:16:14 GMT
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 <bimargulies@gmail.com> wrote:

> From: Benson Margulies <bimargulies@gmail.com>
> Subject: Re: Handling of unrecognised version qualifiers
> To: "Maven Developers List" <dev@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 <jdcasey@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


Mime
View raw message