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<[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]
--
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]
