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 <[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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
