Hi,
The current versioning implementation is IMHO too 'tight'. For instance,
2.0.0alpha1 is parsed as '0.0.0.0' with a qualifier of '2.0.0alpha1',
whereas this should
be parsed in the same way as 2.0.0.alpha.1 or 2.0.0-alpha-1.
Here's a proposal:
- don't use the current 4-digit limitation, but instead list with a
random amount of entries
- entries are separated by dots or dashes
- entries are separated by transition to/from alpha to numeric
- sub-lists are indicated by '-'
- entries can be either: string, integer, or sublist
- versions are compared entry by entry, where we have 3 options;
* integer <=> integer: normal numerical compare
* integer <=> string: integers are newer
* integer <=> list: integers are newer
* string <=> string: if it's a qualifier, qualifier compare, else
lexical compare,
taking into account if either is a qualifier.
* string <=> list: list is newer
* list <=> list: recursion, same as a 'top-level' version compare.
Where one list is shorter,
'0' is assumed (so 2.0 <=> 2 == 0, 2.0-alpha <=> 2.0 =>
2.0-alpha <=> 2.0.0 = -1 (2.0 = newer))
Now for some examples to explain the rules above:
(note; i'm using the following notation:
[1, 0] is a list with items 1, 0;
[1, 0, [2, 3]] is a list with items 1, 0, [2, 3] where the latter
is a sublist)
Version parsing:
'1.0': [1, 0]
'1.0.0.0.0' [1, 0, 0, 0, 0]
'1.0-2.3': [1, 0, [2, 3]]
'1.0-2-3': [1, 0, [2, [3]]]
'1.0-alpha-1': [1, 0, ["alpha", [1]]]
'1.0alpha1': [1, 0, ["alpha", [1]]] or [1, 0, "alpha", 1], which is
the current implementation (see bottom)
String sorting (qualifiers)
SNAPSHOT < alpha < beta < gamma < rc < ga < unknown(lexical sort) < ''
< sp
(ga = latest rc, final version
'' = no qualifier, final version
sp = service pack, improvement/addition on final release)
usually systems either use '' or ga, not both.
so 1.0-rc3 < 1.0-ga == 1.0 < 1.0-sp1 < 1.0.1
Comparing;
1)
1.0-SNAPSHOT <=> 1.0
[1, 0, [SNAPSHOT]] <=> [1, 0]
the first 2 items are equal, the last is assumed to be 0 for the right
hand, and thus is newer.
2)
1.0-beta-3 <=> 1.0-alpha-4
[1, 0, ["beta", [3]]] <=> [1, 0, ["alpha", [4]]]
same here, then "beta" is newer then "alpha" so the first half wins
3)
1.0-2.3 <=> 1.0-2-3
[1, 0, [2, 3]] <=> [1, 0, [2, [3]]]
first 2 items are the same, then this is left;
[2, 3] <=> [2, [3]]
first item is the same, second item: the left list wins since the
right one is a sublist.
So 1.0-2.3 is newer than 1.0-2-3 (which seems right: -[digit]
usually indicates a maintainer update,
and '.' here a bugfix version, though i doubt this will be a valid
usecase).
4)
1.0-alpha-2 <=> 1.0alpha2
The current implementation parses this as:
[1, 0, [alpha, [2]]] <=> [1, 0, alpha, 2]
The right one is newer.
If we change parsing '1.0alpha2' by using sublists on alpha<->digit
transition, both will parse
as [1, 0, ["alpha", [2]]. I think this is preferrable.
we may need to flatten the list or assume alpha<->digit transitions
create a new sublist.
So, I've given both a way to represent versions in a generic way, and
an algorithm to compare versions.
Replacing DefaultArtifactVersion is easy enough (see bottom), though
ranges may be a bit more complicated.
This scheme will support the eclipse version numbering:
http://wiki.eclipse.org/index.php/Version_Numbering
(basically: major.minor.bugfix.qualifier: [major, minor, bugfix,
qualifier]
and Jboss:
http://docs.jboss.org/process-guide/en/html/release-procedure.html,
(basically: X.YY.ZZ.Q*, for instance 1.2.3.alpha4: [1, 2, 3, "alpha", 4]
Maven: major.minor(.bugfix)?(-(alpha|beta|rc)-X)? which will be:
[ major, minor, bugfix?, [ alpha|beta|rc, [X] ]
I'll probably miss some usecases or got some things wrong, but if we
do not support some sort of <versionScheme>
tag in the POM, we want to be able to accommodate versioning in a most
generic way, and I think this comes close.
I've created an implementation[1] and a unit test[2].
I've had to comment out one assert: 2.0.1-xyz < 2.0.1. I think
generally this is not the case. For example,
the wiki guide to patching plugins states that you could patch a
plugin and change it's version to 2.0-INTERNAL.
In this case, 2.0 would be newer than 2.0-INTERNAL, which renders the
wiki description invalid. In my sample
implementation, 2.0.1-xyz is newer than 2.0.1.
Though should this be required, the code is easily modified to reflect
this.
So, WDYT?
Any additional version schemes that cannot be handled by this?
If this looks ok, then my next challenge will be to support ranges. ;)
[1] http://www.neonics.com/~forge/GenericArtifactVersion.java - put in
maven-artifact/src/main/java/.../versioning/
Note: this one doesn't implement ArtifactVersion since we never
know what the major/minor versions etc.
will be. It could implement it and default to 0 if the item isn't
an integer;
[2] http://www.neonics.com/~forge/GenericArtifactVersionTest.java -
put in maven-artifact/src/test/java/.../versioning/
Note: this test is a copy of the DefaultArtifactVersionTest, with
Default replaced by Generic.
The testVersionParsing is left out since the other unit test
already takes care of checking if this works
okay, and because GenericArtifactVersion doesn't implement
ArtifactVersion.
I've tested for all constructor calls that the toString() method
yields the constructor argument.
-- Kenney
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
