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 <[email protected]> wrote: > From: John Casey <[email protected]> > Subject: Re: Handling of unrecognised version qualifiers > To: "Maven Developers List" <[email protected]> > 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: [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]
