On 12/19/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
Carlos Sanchez wrote:
> Sound like a lot of added complexity that will cause trouble to all
> tooling on top of Maven
>
How so? The current implementation is too complex, this one is pretty
straight forward - it allows for versions of any length.
I meant yours AND current one are both complex, although yours wins ;)
Whatever parser/validation code you write will need to be used in all
tooling, like any IDE pom editor, pom converters,... you may say
that's fine but think that tools could also be implemented in other
languages.
> What about forcing the xml schema to a standard versioning system. If
> it's used then you'll benefit from all Maven goodies. If you just use
> a String Maven will do its best.
>
> It's gonna be more complex for manual editing but being standard xml
> will be easier to implement
>
It's already implemented. ;) Plus my sample implementation supports the current
(limited)
version scheme implementation and so far all others I've come across, which the
current one
doesn't.
This is definitely too verbose. Plus, we cannot force a version numbering scheme
on people, since there are already big projects out there that have a good
version numbering scheme which doesn't fit in this one.
I agree is too verbose, but the same happens with <dependency> and all
the other tags that can be reduced, but losing simplicity. Not using
attributes also makes the pom verbose and nobody questions that.
As I said we can have a pure String representation for those projects
that don't want to follow our suggestion, but they won't have the
added features.
Though the tag you list above looks good, but not for version definitions, but
we could use something like that for version scheme specifications so we can
validate
supplied versions, for instance in a super pom:
<versionScheme>
<component name='major' type='numeric'/>
<component name='minor' optional='true' type='numeric'>
<component name='bug' optional='true' type='numeric'/>
<component name='qualifier' start-separator='-' optional='true' type='string'>
<qualifier>alpha</qualifier>
<qualifier>beta</qualifier>
</component>
<component name='buildnumber' optional='true' type='numeric'/>
</version>
Or, I'd prefer XSD schema notation to specify the above. It could validate a
version like this:
2.0-alpha-3 which is rendered as
(your example, sort of)
<version>
<major>1</major>
<minor>2<minor>
<qualifier>alpha</qualifier>
<buildnumber>123</buildnumber>
</version>
but users would just specify '2.0-alpha-3' in the pom.
-- Kenney
> On 12/18/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
>>
>> 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]
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
