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 <[email protected]> wrote: > From: Benson Margulies <[email protected]> > Subject: Re: Handling of unrecognised version qualifiers > To: "Maven Developers List" <[email protected]> > 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 <[email protected]> > 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: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > -- > > John Casey > > Developer, PMC Member - Apache Maven (http://maven.apache.org) > > Blog: http://www.johnofalltrades.name/ > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
