versioning

[Kenney Westerhof <ke...@apache.org>]

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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Dennis Lundberg <de...@apache.org>]

Kenney Westerhof wrote:
> Richard van der Hoff wrote:
> 
> Hi,
> 
>> Carlos Sanchez wrote:
>>> Sound like a lot of added complexity that will cause trouble to all
>>> tooling on top of Maven
>>
>> Can you justify that with an example, at all?
>>
>>> 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.
>>>
>>> For instance
>>>
>>> <version>
>>>  <major>1</major>
>>>  <minor>2<minor>
>>>  <bug>1</bug>
>>>  <buildnumber>123</buildnumber>
>>> </version>
>>
>> The problem is basically that this simply isn't powerful enough to 
>> cover all the various versioning schemes there are in the wild. 
>> Suggesting forcing everybody to conform to your idea of versioning 
>> isn't at all helpful; similarly imposing a complex mapping between 
>> upstream and maven versions for a project is unattractive.
> 
> I agree. As i said in another mail, something like this could be used to 
> specify
> a weird versioning scheme. Versions are ONLY needed for comparison, 
> nothing else, so that's
> where proper parsing and comparing comes into play. Limiting freedom in 
> using version schemes just so we can compare them is not the way to go 
> IMHO.
> 
>> Furthermore you don't leave any scope for extension such as might be 
>> required for local modifications of a project.
>>
>> Stéphane also suggested forcing a particular versioning convention on 
>> everybody - the same argument applies.
>>
>> Regarding Kenney's proposal: as discussed on #maven, all sounds very 
>> sensible to me. I'm still fishing for, and failing to find, examples 
>> of failures for projects where people invert the precedence of . and 
>> -; however anyone doing that probably deserves what they get.
> 
> Still waiting.. ;)   Did we discuss this one: 1.0-2.3  <=> 1.0-2-3, 
> which is newer? My algorithm would say 1.0-2.3.
> 
>> I don't think it would be unreasonable to expect a project's maven 
>> versions to be consistent with 1.0alpha2 vs 1.0-alpha-3 - so jumping 
>> through hoops to make this work may not be worthwhile.
> 
> True. But as others suggested, when project leads are replaced, version 
> schemes
> may change also. Though I think that if that's the case, then they'll 
> probably
> stick to the current scheme until a final (bugfix) release has been 
> made, so
> you will probably never find 1.0alpha2 <=> 1.0-alpha-3, but rather 
> 1.0alpha2 <=> 1.1-alpha-2. I think this is a limitation we could easily 
> impose.
> 
>> Is it a given that we want SNAPSHOT < alpha < beta < gamma < rc < ga ? 
>> What happens when we've released an alpha, but want to continue 
>> hacking on SNAPSHOTs before releasing another? we want SNAPSHOT 
>> between rc and ga, no?
> 
> Yes we do. But, when trunk always has 2.0-SNAPSHOT, you don't know of an 
> alpha
> or beta or rc has been released yet. I'd say:
> 1.0-SNAPSHOT < 1.0-alpha-1-SNAPSHOT < 1.0-alpha-2-SNAPSHOT < ... < 
> 1.0-rc1 < 1.0-rc2-SNAPSHOT.
> 
> Snapshots also have to be possible before the first alpha (which is 
> pretty common to do),
> and if we allow SNAPSHOT's to be present everywhere (and use it as a 
> qualifier, so:
> SNAPSHOT < alpha < SNAPSHOT < beta <..), we can never compare with 
> snapshots.
> 
>  From experience I'd say people start out with 1.0-SNAPSHOT, and later 
> do 1.0-rc-1. Then before
> the ga is released, they don't revert back to 1.0-SNAPSHOT (or 
> shouldn't, i've seen people do it). This
> produces unpredictable results.

maven-site-plugin anyone? :)

>> Also, does "unknown(lexical sort) < ''" not conflict with "In my sample
>> implementation, 2.0.1-xyz is newer than 2.0.1."? 
> 
> No it doesn't. The current implementation assumes 2.0.1 is newer than 
> 2.0.1-xyz.
> 
> 
> To quote Barrie Treloar who quoted a book:
> 
>  quote BBWM page 60: "It is intended that the qualifier indicates a version
>  prior to release"  
>  thus 2.0.1-xyz < 2.0.1 is correct.
>  The -INTERNAL was always meant to be a qualifier.
>  Thus: 2.0-SNAPSHOT < 2.0-INTERNAL < 2.0
> I'm missing some context here, but 'xyz' is not a KNOWN qualifier. Our 
> qualifiers
> are 'alpha', 'beta', 'rc, 'ga', 'sp'. If it's a random string, and we 
> don't call it a qualifier,
> it could well mean a newer version.
> 
> The problem is where to place strings that are unknown qualifiers:
> 
>  alpha < beta < rc < ga <  (here?) < "" < (here?) < sp < (here?)
> 
> 
>> I may just be misunderstanding your explanation, but if you could 
>> clarify what exactly happens when a given component isn't present, and 
>> for unrecognised qualifiers, that would be useful.
> 
> Right now: if a component is not present, in the case of:
> 
> integer <=> null:  integer==0 ? 0 : 1 (this fixes '2.0' <=> '2' which is 
> 0, and 2.1 <=> 2 which is 1)
> 
> list    <=> null: does a compare for list <=> [empty list], which 
> finally results in either integer <=> null or string <=> null
> 
> string <=> null:   see the 'alpha < beta' list above.
> 
>                   Use the empty string instead of null, then compare 
> string <=> "". So when comparing
>                   1-alpha with 1, this is the same as comparing 
> "1-alpha" and "1-". Which one is newer
>                   depends on wheter 'string' is listed before or after 
> the "" in the list above.
> 
>                   Algorithm for string <=> string:
> 
>                   Construct a string for the left hand side, and one for 
> the right hand side, and compare those
>                   lexically:
> 
>                   construct a string: if the string is a known 
> qualifier, use the index in the qualifier list (alpha=0,
>                   rc=2 etc),                   otherwise concat the size 
> of the qualifier list (6) and the string ("6-string").
> 
>                   So, "alpha" <=> ""       ->    '0' <=> '5'     = -1
>                       "foo"   <=> "alpha"  ->    '6-foo' <=> '0' = 1  
> (but like I said, this is up for debate.
> 
>     
> -- Kenney
>                  
>> I've found the current scheme quite limited, and certainly capable of 
>> producing unexpected results, so I'm definitely in favour of making 
>> some changes here.
>>
>> Best regards,
>>
>> Richard


-- 
Dennis Lundberg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Kenney Westerhof <ke...@apache.org>]

Richard van der Hoff wrote:
> Kenney Westerhof wrote:
>> Richard van der Hoff wrote:
>>
>> Hi,
>>
>>> Carlos Sanchez wrote: Regarding Kenney's proposal: as discussed on
>>> #maven, all sounds very sensible to me. I'm still fishing for, and
>>> failing to find, examples of failures for projects where people
>>> invert the precedence of . and -; however anyone doing that
>>> probably deserves what they get.
>>
>> Still waiting.. ;)   Did we discuss this one: 1.0-2.3  <=> 1.0-2-3, 
>> which is newer? My algorithm would say 1.0-2.3.
> 
> I don't think we discussed exactly that. I think your algorithm is
> probably right here. However, you've now helped me find the problem I
> was fishing for. My imaginary project separates versions with - and
> build numbers with .; so I have
> 
> 1-0.193
> 1-0.204
> 1-1.897
> 
> Oops! I need to release a bugfix to 1-0: 1-0-1.596
> 
> With your algorithm, we have (I think) 1-0-1.596 < 1-0.193, which is
> wrong for my (crazy) versioning system. But, as I said, I deserve what I
> get for doing this.

Correct;

1-0-1.596 = [1, [0, [1, 596]]]
1-0.193   = [1, [0, 193]]

comes down to comparing [1, 596] with 193.

It's easily changed, though I'm not sure what the impact would be.

And you would deserve it, definitely ;)

> There will always be some corner case we don't quite cover correctly; I
> don't think we should let this worry us or act as an argument against
> improving the status quo, provided we get most sane cases covered. We 
> just need to make sure the exact algorithm is documented :).

I totally agree.

>>> I don't think it would be unreasonable to expect a project's maven
>>>  versions to be consistent with 1.0alpha2 vs 1.0-alpha-3 - so
>>> jumping through hoops to make this work may not be worthwhile.
>>
>> True. But as others suggested, when project leads are replaced,
>> version schemes may change also. Though I think that if that's the
>> case, then they'll probably stick to the current scheme until a final
>> (bugfix) release has been made, so you will probably never find
>> 1.0alpha2 <=> 1.0-alpha-3, but rather 1.0alpha2 <=> 1.1-alpha-2. I
>> think this is a limitation we could easily impose.
> 
> Agreed.
> 
>>> Is it a given that we want SNAPSHOT < alpha < beta < gamma < rc <
>>> ga ? What happens when we've released an alpha, but want to
>>> continue hacking on SNAPSHOTs before releasing another? we want
>>> SNAPSHOT between rc and ga, no?
>>
>> Yes we do. But, when trunk always has 2.0-SNAPSHOT, you don't know of
>> an alpha or beta or rc has been released yet. I'd say: 1.0-SNAPSHOT <
>> 1.0-alpha-1-SNAPSHOT < 1.0-alpha-2-SNAPSHOT < ... < 1.0-rc1 <
>> 1.0-rc2-SNAPSHOT.
>>
>> Snapshots also have to be possible before the first alpha (which is 
>> pretty common to do), and if we allow SNAPSHOT's to be present
>> everywhere (and use it as a qualifier, so: SNAPSHOT < alpha <
>> SNAPSHOT < beta <..), we can never compare with snapshots.
> 
> SNAPSHOT is a bit special anyway... If we have alpha < beta < SNAPSHOT < 
> ga, then people who want a SNAPSHOT will get the last snapshot before 
> the main release (regardless of the presence of alphas), and people who 
> don't will get the latest non-SNAPSHOT? I don't quite understand what 
> you mean here.

Well, we usually release say 1.0-SNAPSHOT first a few times, then 1.0-beta-1-SNAPSHOT,
then 1.0-beta-1, etc.

SNAPSHOT means 'working towards version'. It should be a suffix to the next final
release made. So if your next release is 1.0-alpha-1, use 1.0-alpha-1-SNAPSHOT,
not 1.0-SNAPSHOT.

But then again, maybe there's no problem in using snapshots everywhere - you're only
interested in the latest one anyway, and this could be a SNAPSHOT from pre-1.0-alpha-X,
or a SNAPSHOT from pre 1.0. Guess it's not a problem after all. 
I think the SNAPSHOT qualifier should be removed from my implementation, since it's not really
a qualifier. SNAPSHOT versions are resolved from the repository first anyway.

With this in mind, comparing 1.0-SNAPSHOT with 1.0-alpha-1 would cause problems.
Depending on wheter 1.0-SNAPSHOT is a pre-alpha-1 release, or a pre 1.0 release,
it would be older or newer.
Maybe whenever a 1.0-SNAPSHOT is encountered, it should also resolve to the latest 1.0-*
version released. 
For instance, we have in the repository, in order of deploying:
- 1.0-SNAPSHOT
- 1.0-alpha-1-SNAPSHOT 
- 1.0-alpha-1
- 1.0-SNAPSHOT
- 1.0-rc-1

Then 1.0-SNAPSHOT should resolve to 1.0-rc-1. This requires some work on snapshot resolution,
but SNAPSHOT in a dependency means 'get me the latest version' (whereas SNAPSHOT in the 
project's version tag means: 'working towards').

>> From experience I'd say people start out with 1.0-SNAPSHOT, and later
>> do 1.0-rc-1. Then before the ga is released, they don't revert back
>> to 1.0-SNAPSHOT (or shouldn't, i've seen people do it). This produces
>> unpredictable results.
> 
> So your recommendation is, once you want to make the final release, to 
> go straight from 1.0-rc-N-SNAPSHOT to 1.0, without ever releasing 
> 1.0-rc-N (and similarly for transition into alpha, beta and rc stages)? 
> That's fine, provided it's documented :).

Depends on the project's release management. At maven we use a few different schemes.
This is once I've seen: once we release 1.0-alpha-1, the pom is updated to 
1.0-alpha-2-SNAPSHOT. When no alpha-2 is needed, the pom is updated to beta-1-SNAPSHOT.
Same applies for the final release - when no 1.0-beta-X is planned, the pom is updated to 1.0-SNAPSHOT
(1.0 being the final beta, if we don't use rc's).

Some even use this scheme:
trunk always has 1.0-SNAPSHOT; when alpha-x is released, a branch is created for alpha-(x+1).
When no more alpha's are released, a beta is released, creating a new branch (or updating the alpha branch).
In the mean time, both alpha/beta snapshots and 1.0 snapshots are published (which could cause some serious
headaches with the current implementation).

>>> Also, does "unknown(lexical sort) < ''" not conflict with "In my
>>> sample implementation, 2.0.1-xyz is newer than 2.0.1."?
>>
>> No it doesn't. The current implementation assumes 2.0.1 is newer than
>>  2.0.1-xyz.
> 
> So '' < unknown(lexical sort) ? Anyway, you say this is up for debate, 
> fine.

That's what i'm proposing, yes. It conflicts with to the current implementation.
The problem with the current implementation is that '1.0-abc' is considered older
than 1.0-alpha1, but 1.0-xyz is considered newer than 1.0-alpha-1. This lexical sorting,
together with qualifier length and prefix checking, is not intuitive.


-- Kenney

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Richard van der Hoff <ri...@mxtelecom.com>]

Kenney Westerhof wrote:
> Richard van der Hoff wrote:
> 
> Hi,
> 
>> Carlos Sanchez wrote: Regarding Kenney's proposal: as discussed on
>> #maven, all sounds very sensible to me. I'm still fishing for, and
>> failing to find, examples of failures for projects where people
>> invert the precedence of . and -; however anyone doing that
>> probably deserves what they get.
> 
> Still waiting.. ;)   Did we discuss this one: 1.0-2.3  <=> 1.0-2-3, 
> which is newer? My algorithm would say 1.0-2.3.

I don't think we discussed exactly that. I think your algorithm is
probably right here. However, you've now helped me find the problem I
was fishing for. My imaginary project separates versions with - and
build numbers with .; so I have

1-0.193
1-0.204
1-1.897

Oops! I need to release a bugfix to 1-0: 1-0-1.596

With your algorithm, we have (I think) 1-0-1.596 < 1-0.193, which is
wrong for my (crazy) versioning system. But, as I said, I deserve what I
get for doing this.

There will always be some corner case we don't quite cover correctly; I
don't think we should let this worry us or act as an argument against
improving the status quo, provided we get most sane cases covered. We 
just need to make sure the exact algorithm is documented :).

>> I don't think it would be unreasonable to expect a project's maven
>>  versions to be consistent with 1.0alpha2 vs 1.0-alpha-3 - so
>> jumping through hoops to make this work may not be worthwhile.
> 
> True. But as others suggested, when project leads are replaced,
> version schemes may change also. Though I think that if that's the
> case, then they'll probably stick to the current scheme until a final
> (bugfix) release has been made, so you will probably never find
> 1.0alpha2 <=> 1.0-alpha-3, but rather 1.0alpha2 <=> 1.1-alpha-2. I
> think this is a limitation we could easily impose.

Agreed.

>> Is it a given that we want SNAPSHOT < alpha < beta < gamma < rc <
>> ga ? What happens when we've released an alpha, but want to
>> continue hacking on SNAPSHOTs before releasing another? we want
>> SNAPSHOT between rc and ga, no?
> 
> Yes we do. But, when trunk always has 2.0-SNAPSHOT, you don't know of
> an alpha or beta or rc has been released yet. I'd say: 1.0-SNAPSHOT <
> 1.0-alpha-1-SNAPSHOT < 1.0-alpha-2-SNAPSHOT < ... < 1.0-rc1 <
> 1.0-rc2-SNAPSHOT.
> 
> Snapshots also have to be possible before the first alpha (which is 
> pretty common to do), and if we allow SNAPSHOT's to be present
> everywhere (and use it as a qualifier, so: SNAPSHOT < alpha <
> SNAPSHOT < beta <..), we can never compare with snapshots.

SNAPSHOT is a bit special anyway... If we have alpha < beta < SNAPSHOT < 
ga, then people who want a SNAPSHOT will get the last snapshot before 
the main release (regardless of the presence of alphas), and people who 
don't will get the latest non-SNAPSHOT? I don't quite understand what 
you mean here.

> From experience I'd say people start out with 1.0-SNAPSHOT, and later
> do 1.0-rc-1. Then before the ga is released, they don't revert back
> to 1.0-SNAPSHOT (or shouldn't, i've seen people do it). This produces
> unpredictable results.

So your recommendation is, once you want to make the final release, to 
go straight from 1.0-rc-N-SNAPSHOT to 1.0, without ever releasing 
1.0-rc-N (and similarly for transition into alpha, beta and rc stages)? 
That's fine, provided it's documented :).

>> Also, does "unknown(lexical sort) < ''" not conflict with "In my
>> sample implementation, 2.0.1-xyz is newer than 2.0.1."?
> 
> No it doesn't. The current implementation assumes 2.0.1 is newer than
>  2.0.1-xyz.

So '' < unknown(lexical sort) ? Anyway, you say this is up for debate, fine.

-- 
Richard van der Hoff <ri...@mxtelecom.com>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Kenney Westerhof <ke...@apache.org>]

Richard van der Hoff wrote:

Hi,

> Carlos Sanchez wrote:
>> Sound like a lot of added complexity that will cause trouble to all
>> tooling on top of Maven
> 
> Can you justify that with an example, at all?
> 
>> 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.
>>
>> For instance
>>
>> <version>
>>  <major>1</major>
>>  <minor>2<minor>
>>  <bug>1</bug>
>>  <buildnumber>123</buildnumber>
>> </version>
> 
> The problem is basically that this simply isn't powerful enough to cover 
> all the various versioning schemes there are in the wild. Suggesting 
> forcing everybody to conform to your idea of versioning isn't at all 
> helpful; similarly imposing a complex mapping between upstream and maven 
> versions for a project is unattractive.

I agree. As i said in another mail, something like this could be used to specify
a weird versioning scheme. Versions are ONLY needed for comparison, nothing else, so that's
where proper parsing and comparing comes into play. Limiting freedom in using version schemes 
just so we can compare them is not the way to go IMHO.

> Furthermore you don't leave any scope for extension such as might be 
> required for local modifications of a project.
> 
> Stéphane also suggested forcing a particular versioning convention on 
> everybody - the same argument applies.
> 
> Regarding Kenney's proposal: as discussed on #maven, all sounds very 
> sensible to me. I'm still fishing for, and failing to find, examples of 
> failures for projects where people invert the precedence of . and -; 
> however anyone doing that probably deserves what they get.

Still waiting.. ;)   Did we discuss this one: 1.0-2.3  <=> 1.0-2-3, which is newer? 
My algorithm would say 1.0-2.3.

> I don't think it would be unreasonable to expect a project's maven 
> versions to be consistent with 1.0alpha2 vs 1.0-alpha-3 - so jumping 
> through hoops to make this work may not be worthwhile.

True. But as others suggested, when project leads are replaced, version schemes
may change also. Though I think that if that's the case, then they'll probably
stick to the current scheme until a final (bugfix) release has been made, so
you will probably never find 1.0alpha2 <=> 1.0-alpha-3, but rather 
1.0alpha2 <=> 1.1-alpha-2. I think this is a limitation we could easily impose.
 
> Is it a given that we want SNAPSHOT < alpha < beta < gamma < rc < ga ? 
> What happens when we've released an alpha, but want to continue hacking 
> on SNAPSHOTs before releasing another? we want SNAPSHOT between rc and 
> ga, no?

Yes we do. But, when trunk always has 2.0-SNAPSHOT, you don't know of an alpha
or beta or rc has been released yet. I'd say: 

1.0-SNAPSHOT < 1.0-alpha-1-SNAPSHOT < 1.0-alpha-2-SNAPSHOT < ... < 1.0-rc1 < 1.0-rc2-SNAPSHOT.

Snapshots also have to be possible before the first alpha (which is pretty common to do),
and if we allow SNAPSHOT's to be present everywhere (and use it as a qualifier, so:
SNAPSHOT < alpha < SNAPSHOT < beta <..), we can never compare with snapshots.

From experience I'd say people start out with 1.0-SNAPSHOT, and later do 1.0-rc-1. Then before
the ga is released, they don't revert back to 1.0-SNAPSHOT (or shouldn't, i've seen people do it). This
produces unpredictable results.

> Also, does "unknown(lexical sort) < ''" not conflict with "In my sample
> implementation, 2.0.1-xyz is newer than 2.0.1."? 

No it doesn't. The current implementation assumes 2.0.1 is newer than 2.0.1-xyz.


To quote Barrie Treloar who quoted a book:

  quote BBWM page 60: "It is intended that the qualifier indicates a version
  prior to release" 
  
  thus 2.0.1-xyz < 2.0.1 is correct.
  The -INTERNAL was always meant to be a qualifier.
  Thus: 2.0-SNAPSHOT < 2.0-INTERNAL < 2.0 

I'm missing some context here, but 'xyz' is not a KNOWN qualifier. Our qualifiers
are 'alpha', 'beta', 'rc, 'ga', 'sp'. If it's a random string, and we don't call it a qualifier,
it could well mean a newer version.

The problem is where to place strings that are unknown qualifiers:

  alpha < beta < rc < ga <  (here?) < "" < (here?) < sp < (here?)


> I may just be 
> misunderstanding your explanation, but if you could clarify what exactly 
> happens when a given component isn't present, and for unrecognised 
> qualifiers, that would be useful.

Right now: if a component is not present, in the case of:

integer <=> null:  integer==0 ? 0 : 1 (this fixes '2.0' <=> '2' which is 0, and 2.1 <=> 2 which is 1)

list    <=> null: does a compare for list <=> [empty list], which finally results in either integer <=> null or string <=> null

string <=> null:   see the 'alpha < beta' list above.

                   Use the empty string instead of null, then compare string <=> "". So when comparing
                   1-alpha with 1, this is the same as comparing "1-alpha" and "1-". Which one is newer
                   depends on wheter 'string' is listed before or after the "" in the list above.

                   Algorithm for string <=> string:

                   Construct a string for the left hand side, and one for the right hand side, and compare those
                   lexically:

                   construct a string: if the string is a known qualifier, use the index in the qualifier list (alpha=0,
                   rc=2 etc), 
                   otherwise concat the size of the qualifier list (6) and the string ("6-string").

                   So, "alpha" <=> ""       ->    '0' <=> '5'     = -1
                       "foo"   <=> "alpha"  ->    '6-foo' <=> '0' = 1  (but like I said, this is up for debate.
 
	
-- Kenney
                   
> I've found the current scheme quite limited, and certainly capable of 
> producing unexpected results, so I'm definitely in favour of making some 
> changes here.
> 
> Best regards,
> 
> Richard
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Kenney Westerhof <ke...@apache.org>]

Stephane Nicoll wrote:
> On 12/19/06, Richard van der Hoff <ri...@mxtelecom.com> wrote:
>> Stéphane also suggested forcing a particular versioning convention on
>> everybody - the same argument applies.
> 
> I am not sure that's what I meant. If we want to be able to compare
> versions we need to standardize things. That sounds obvious to me.
> Maven is about standardization, I think it would be good if we tackle
> the component numbering scheme.
> 

Standardization is good. But, we don't need a standard versioning scheme just to compare
different versions, because when versions are compared, they are always for the same artifact.
We can assume that people use a consistent versioning scheme for one project. If they don't then
maven can't help them. 

> I think that the best option would be to provide a defaulting and
> allowing anyone to plug in a custom scheme (and the related algorithm
> used to compare the versions)

I've proposed this too, a while back, at the wiki (so +1) :)

The default handling would have to be as robust as possible, allowing for as much usecases
as we can, without the code being too complex, and without the need to customize often.
Convention over configuration should prevail - or in this case, default algorithms over
configuration.

So we should definitely support pluggable versioning schemes, someday, but for now I think
(without having to modify the pom), my parsing/comparing proposal is a step in the right direction
to be as generic and flexible as we can to support whatever schemes are out there and used widely
right now. At least, that was my goal, and I still would like to see some examples of schemes
that this one doesn't handle properly.

-- Kenney

> 
> WDYT?
> 
> Stéphane
> 
> 
> 
>>
>> Regarding Kenney's proposal: as discussed on #maven, all sounds very
>> sensible to me. I'm still fishing for, and failing to find, examples of
>> failures for projects where people invert the precedence of . and -;
>> however anyone doing that probably deserves what they get.
>>
>> I don't think it would be unreasonable to expect a project's maven
>> versions to be consistent with 1.0alpha2 vs 1.0-alpha-3 - so jumping
>> through hoops to make this work may not be worthwhile.
>>
>> Is it a given that we want SNAPSHOT < alpha < beta < gamma < rc < ga ?
>> What happens when we've released an alpha, but want to continue hacking
>> on SNAPSHOTs before releasing another? we want SNAPSHOT between rc and
>> ga, no?
>>
>> Also, does "unknown(lexical sort) < ''" not conflict with "In my sample
>> implementation, 2.0.1-xyz is newer than 2.0.1."? I may just be
>> misunderstanding your explanation, but if you could clarify what exactly
>> happens when a given component isn't present, and for unrecognised
>> qualifiers, that would be useful.
>>
>> I've found the current scheme quite limited, and certainly capable of
>> producing unexpected results, so I'm definitely in favour of making some
>> changes here.
>>
>> Best regards,
>>
>> Richard
>>
>> -- 
>> Richard van der Hoff <ri...@mxtelecom.com>
>> Telephony Gateways Project Manager
>> Tel: +44 (0) 845 666 7778
>> http://www.mxtelecom.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Stephane Nicoll <st...@gmail.com>]

On 12/19/06, Richard van der Hoff <ri...@mxtelecom.com> wrote:
> Stéphane also suggested forcing a particular versioning convention on
> everybody - the same argument applies.

I am not sure that's what I meant. If we want to be able to compare
versions we need to standardize things. That sounds obvious to me.
Maven is about standardization, I think it would be good if we tackle
the component numbering scheme.

I think that the best option would be to provide a defaulting and
allowing anyone to plug in a custom scheme (and the related algorithm
used to compare the versions)

WDYT?

Stéphane



>
> Regarding Kenney's proposal: as discussed on #maven, all sounds very
> sensible to me. I'm still fishing for, and failing to find, examples of
> failures for projects where people invert the precedence of . and -;
> however anyone doing that probably deserves what they get.
>
> I don't think it would be unreasonable to expect a project's maven
> versions to be consistent with 1.0alpha2 vs 1.0-alpha-3 - so jumping
> through hoops to make this work may not be worthwhile.
>
> Is it a given that we want SNAPSHOT < alpha < beta < gamma < rc < ga ?
> What happens when we've released an alpha, but want to continue hacking
> on SNAPSHOTs before releasing another? we want SNAPSHOT between rc and
> ga, no?
>
> Also, does "unknown(lexical sort) < ''" not conflict with "In my sample
> implementation, 2.0.1-xyz is newer than 2.0.1."? I may just be
> misunderstanding your explanation, but if you could clarify what exactly
> happens when a given component isn't present, and for unrecognised
> qualifiers, that would be useful.
>
> I've found the current scheme quite limited, and certainly capable of
> producing unexpected results, so I'm definitely in favour of making some
> changes here.
>
> Best regards,
>
> Richard
>
> --
> Richard van der Hoff <ri...@mxtelecom.com>
> Telephony Gateways Project Manager
> Tel: +44 (0) 845 666 7778
> http://www.mxtelecom.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Richard van der Hoff <ri...@mxtelecom.com>]

Carlos Sanchez wrote:
> Sound like a lot of added complexity that will cause trouble to all
> tooling on top of Maven

Can you justify that with an example, at all?

> 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.
> 
> For instance
> 
> <version>
>  <major>1</major>
>  <minor>2<minor>
>  <bug>1</bug>
>  <buildnumber>123</buildnumber>
> </version>

The problem is basically that this simply isn't powerful enough to cover 
all the various versioning schemes there are in the wild. Suggesting 
forcing everybody to conform to your idea of versioning isn't at all 
helpful; similarly imposing a complex mapping between upstream and maven 
versions for a project is unattractive.

Furthermore you don't leave any scope for extension such as might be 
required for local modifications of a project.

Stéphane also suggested forcing a particular versioning convention on 
everybody - the same argument applies.

Regarding Kenney's proposal: as discussed on #maven, all sounds very 
sensible to me. I'm still fishing for, and failing to find, examples of 
failures for projects where people invert the precedence of . and -; 
however anyone doing that probably deserves what they get.

I don't think it would be unreasonable to expect a project's maven 
versions to be consistent with 1.0alpha2 vs 1.0-alpha-3 - so jumping 
through hoops to make this work may not be worthwhile.

Is it a given that we want SNAPSHOT < alpha < beta < gamma < rc < ga ? 
What happens when we've released an alpha, but want to continue hacking 
on SNAPSHOTs before releasing another? we want SNAPSHOT between rc and 
ga, no?

Also, does "unknown(lexical sort) < ''" not conflict with "In my sample
implementation, 2.0.1-xyz is newer than 2.0.1."? I may just be 
misunderstanding your explanation, but if you could clarify what exactly 
happens when a given component isn't present, and for unrecognised 
qualifiers, that would be useful.

I've found the current scheme quite limited, and certainly capable of 
producing unexpected results, so I'm definitely in favour of making some 
changes here.

Best regards,

Richard

-- 
Richard van der Hoff <ri...@mxtelecom.com>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Kenney Westerhof <ke...@apache.org>]

Carlos Sanchez wrote:
> On 12/19/06, Kenney Westerhof <ke...@apache.org> wrote:
>> > 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.
>>
>> I don't see why that's necessary - ArtifactVersion implementations are 
>> only used to resolve
>> version conflicts, limit ranges, and other stuff only necessary when 
>> running Maven.
>> You can mix and match any version strings you want using any IDE or 
>> pom editing tool. I don't
>> validate any version, I just parse it and that always works. It has 
>> some rules as to how
>> to interpret version components in order to be able to compare them, 
>> but again, that's just
>> needed for version conflict resolution within maven itself.
>>
>> If you want maven to be able to tell you wheter some version is newer 
>> or older or equal to another
>> version, you have a few limitations on what version schemes you can use:
>>
>> 1) elements more to the left are more important than elements more to 
>> the right
>> 2) some qualifiers have special meanings w.r.t. ordering
>>
>> Other than that there are no limitations, unlike the current 
>> implementation.
>>
> 
> imagine in the IDE you want to present an ordered list of available
> artifacts, that will run outside of maven

Not our problem. ;) 

It can use maven-artifact's version implementation to sort the versions,
or get the source and port it to ruby or whatever language the IDE is written in,
and use that.

There's only 1 class here, which has 2 methods: the string constructor to parse the version,
and a compareTo interface (implementation of comparable). That's not a lot of code to
use in tooling.


-- Kenney

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Carlos Sanchez <ca...@apache.org>]

On 12/19/06, Kenney Westerhof <ke...@apache.org> wrote:
> > 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.
>
> I don't see why that's necessary - ArtifactVersion implementations are only used to resolve
> version conflicts, limit ranges, and other stuff only necessary when running Maven.
> You can mix and match any version strings you want using any IDE or pom editing tool. I don't
> validate any version, I just parse it and that always works. It has some rules as to how
> to interpret version components in order to be able to compare them, but again, that's just
> needed for version conflict resolution within maven itself.
>
> If you want maven to be able to tell you wheter some version is newer or older or equal to another
> version, you have a few limitations on what version schemes you can use:
>
> 1) elements more to the left are more important than elements more to the right
> 2) some qualifiers have special meanings w.r.t. ordering
>
> Other than that there are no limitations, unlike the current implementation.
>

imagine in the IDE you want to present an ordered list of available
artifacts, that will run outside of maven



-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Kenney Westerhof <ke...@apache.org>]

Carlos Sanchez wrote:
> On 12/19/06, Kenney Westerhof <ke...@apache.org> 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 ;)

In complexity? Possibly ;) But added complexity means added flexibility, in this case.
The original code has all edge cases hardcoded.
 
> 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.

I don't see why that's necessary - ArtifactVersion implementations are only used to resolve
version conflicts, limit ranges, and other stuff only necessary when running Maven.
You can mix and match any version strings you want using any IDE or pom editing tool. I don't
validate any version, I just parse it and that always works. It has some rules as to how
to interpret version components in order to be able to compare them, but again, that's just
needed for version conflict resolution within maven itself.

If you want maven to be able to tell you wheter some version is newer or older or equal to another
version, you have a few limitations on what version schemes you can use:

1) elements more to the left are more important than elements more to the right
2) some qualifiers have special meanings w.r.t. ordering

Other than that there are no limitations, unlike the current implementation.

(more below)

>> > 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.

Partially true. having a string representation should provide for some flexible, sensible,
default processing. I don't agree that when you don't specify the complex version tag,
you have no version numbering at all, or just string compares, or even the current implementation.

Version strings have a pretty simple grammar, and what you're proposing is to specify another grammar,
where elements aren't separated by dots or dashes, but by xml tags.

I think that's a severe limitation compared to using version strings, and it doesn't add anything
to support other version schemes or support a different version ordering.

The complexity is not in the grammar, but in the version ordering.

The only solution that makes this customizable I've seen on this thread is the one where you
specify a 'version plugin' with a Version implementation that takes care of sorting for you.


-- Kenney

> 
>>
>> 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 <ke...@apache.org> 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: dev-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: dev-help@maven.apache.org
>> >>
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Jason van Zyl <ja...@maven.org>]

On 19 Dec 06, at 2:08 PM 19 Dec 06, Carlos Sanchez wrote:

> On 12/19/06, Richard van der Hoff <ri...@mxtelecom.com> wrote:
>> Carlos Sanchez wrote:
>> > the repository has some rules and you have to follow them to be
>> > manageable, eg. you name jars artifactId-version.jar and not
>> > otherwise. If there are version rules you'd have to follow, and I
>> > don't see the problem in having a standardized version  
>> convention, as
>> >  we have standardized folder names.
>>
>> As I said before:
>>
>> > The problem is basically that this simply isn't powerful enough to
>> > cover all the various versioning schemes there are in the wild.
>
> 4 or more sections will cover almost all the versioning schemas
>

I'm all for something standard but I think what we have, RPM spec  
versioning, and OSGi are unlikely to converge anytime soon. We need  
support many schemes, so as long as ours can evolve which is must as  
its fragile ATM.

>> > Suggesting forcing everybody to conform to your idea of versioning
>> > isn't at all helpful; similarly imposing a complex mapping between
>> > upstream and maven versions for a project is unattractive.
>
> projects shouldn't care and will end benefiting from standardization
> as they did with folder names. We need to look to other versioning
> standards out there (eg. OSGi) instead of inventing a new one.
> if a non maven project is 1.0-alpha1 we'd simply use 1/0/alpha/1 and
> we can sort the sections
>
>>
>> Which part do you disagree with?
>>
>>
>> --
>> Richard van der Hoff <ri...@mxtelecom.com>
>> Telephony Gateways Project Manager
>> Tel: +44 (0) 845 666 7778
>> http://www.mxtelecom.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> -- 
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                             -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Carlos Sanchez <ca...@apache.org>]

I'd be fine with that too, but in this thread people was complaining
about standardizing other's people versions that don't use dots or are
more complex

On 12/20/06, Max Bowsher <ma...@mxtelecom.com> wrote:
> Carlos Sanchez wrote:
> > I'd just prefer have xml syntax over string parsing and encourage
> > people to use whatever the standard we choose.
>
> Whilst in general, XML can be useful, this might be overusing it.
>
> Versions *must* have some sort of string representation, to be embedded
> in file names.  That representation really ought to be unambiguous and
> parseable.  Given that there's a need to design such a representation, I
> think it would be better to stick with a single representation used
> everywhere, rather than having an alternate XML representation.
>
> Also, humans are used to thinking of versions in terms of strings, and
> projects are going to want to describe their versions in human-targeted
> text.  "We're happy to announce the release of foobar 2.0.1!" is so much
> more pleasant than "We're happy to announce the release of foobar
> <version><major>2</major><minor>0</minor><patch>1</patch><version>!" :-)
>
> Since project developers are inevitably going to think of and speak of
> their projects in terms of compact string forms, better not to introduce
> an alternate form, I think.
>
> Max.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Max Bowsher <ma...@mxtelecom.com>]

Carlos Sanchez wrote:
> I'd just prefer have xml syntax over string parsing and encourage
> people to use whatever the standard we choose.

Whilst in general, XML can be useful, this might be overusing it.

Versions *must* have some sort of string representation, to be embedded
in file names.  That representation really ought to be unambiguous and
parseable.  Given that there's a need to design such a representation, I
think it would be better to stick with a single representation used
everywhere, rather than having an alternate XML representation.

Also, humans are used to thinking of versions in terms of strings, and
projects are going to want to describe their versions in human-targeted
text.  "We're happy to announce the release of foobar 2.0.1!" is so much
more pleasant than "We're happy to announce the release of foobar
<version><major>2</major><minor>0</minor><patch>1</patch><version>!" :-)

Since project developers are inevitably going to think of and speak of
their projects in terms of compact string forms, better not to introduce
an alternate form, I think.

Max.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Carlos Sanchez <ca...@apache.org>]

Seems there is some misunderstanding here, I agree in many things you
said, extend version schemas, allow different schemas to be pluggable
if possible, set a default schema as "standard",...
I'd just prefer have xml syntax over string parsing and encourage
people to use whatever the standard we choose.

On 12/19/06, Kenney Westerhof <ke...@apache.org> wrote:
>
>
> Carlos Sanchez wrote:
> > On 12/19/06, Richard van der Hoff <ri...@mxtelecom.com> wrote:
> >> Carlos Sanchez wrote:
> >> > the repository has some rules and you have to follow them to be
> >> > manageable, eg. you name jars artifactId-version.jar and not
> >> > otherwise. If there are version rules you'd have to follow, and I
> >> > don't see the problem in having a standardized version convention, as
> >> >  we have standardized folder names.
> >>
> >> As I said before:
> >>
> >> > The problem is basically that this simply isn't powerful enough to
> >> > cover all the various versioning schemes there are in the wild.
> >
> > 4 or more sections will cover almost all the versioning schemas
>
> What sections?
>
> If you're talking about the 4 sub-elements of the pom, why limit to 4?
> We've got a good solution now that allows for any number of 'sections'.
>
> >> > Suggesting forcing everybody to conform to your idea of versioning
> >> > isn't at all helpful; similarly imposing a complex mapping between
> >> > upstream and maven versions for a project is unattractive.
> >
> > projects shouldn't care and will end benefiting from standardization
> > as they did with folder names. We need to look to other versioning
> > standards out there (eg. OSGi) instead of inventing a new one.
> > if a non maven project is 1.0-alpha1 we'd simply use 1/0/alpha/1 and
> > we can sort the sections
>
> Folder names? For what?
> Where would you use 1/0/alpha/1?
>
> I'm pro standardization, and we should set an example, but I disagree that we should limit
> or enforce our version scheme to OSGi or any other schemes out there. This will limit the
> applicability of maven in the field. It should be 'convention over configuration', meaning that
> if you follow 'our' standards, it's easy; if you have other company policies, you should be able to
> apply them to maven aswell.
>
> We could adopt the OSGi versioning scheme when developing maven (although we already have one
> which is pretty similar), but I do not want to impose that on maven users.
>
> I'm finding that you're the only one objecting somewhat, and can't find a real reason or usecase
> that contradicts my proposal in any way. All I'm suggesting is that we replace the version
> implementation with something that's more flexible, backwards compatible, and can be used for any
> known scheme. I'm just asking for usecases where the solution won't work.
>
> Extending the POM to add configuration for custom version schemes is another (though related)
> discussion, and can be added later on, though I doubt if it's necessary.
>
> -- Kenney
> >
> >>
> >> Which part do you disagree with?
> >>
> >>
> >> --
> >> Richard van der Hoff <ri...@mxtelecom.com>
> >> Telephony Gateways Project Manager
> >> Tel: +44 (0) 845 666 7778
> >> http://www.mxtelecom.com
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Kenney Westerhof <ke...@apache.org>]

Carlos Sanchez wrote:
> On 12/19/06, Richard van der Hoff <ri...@mxtelecom.com> wrote:
>> Carlos Sanchez wrote:
>> > the repository has some rules and you have to follow them to be
>> > manageable, eg. you name jars artifactId-version.jar and not
>> > otherwise. If there are version rules you'd have to follow, and I
>> > don't see the problem in having a standardized version convention, as
>> >  we have standardized folder names.
>>
>> As I said before:
>>
>> > The problem is basically that this simply isn't powerful enough to
>> > cover all the various versioning schemes there are in the wild.
> 
> 4 or more sections will cover almost all the versioning schemas

What sections?

If you're talking about the 4 sub-elements of the pom, why limit to 4?
We've got a good solution now that allows for any number of 'sections'.

>> > Suggesting forcing everybody to conform to your idea of versioning
>> > isn't at all helpful; similarly imposing a complex mapping between
>> > upstream and maven versions for a project is unattractive.
> 
> projects shouldn't care and will end benefiting from standardization
> as they did with folder names. We need to look to other versioning
> standards out there (eg. OSGi) instead of inventing a new one.
> if a non maven project is 1.0-alpha1 we'd simply use 1/0/alpha/1 and
> we can sort the sections

Folder names? For what?
Where would you use 1/0/alpha/1?

I'm pro standardization, and we should set an example, but I disagree that we should limit
or enforce our version scheme to OSGi or any other schemes out there. This will limit the
applicability of maven in the field. It should be 'convention over configuration', meaning that
if you follow 'our' standards, it's easy; if you have other company policies, you should be able to
apply them to maven aswell.

We could adopt the OSGi versioning scheme when developing maven (although we already have one
which is pretty similar), but I do not want to impose that on maven users.

I'm finding that you're the only one objecting somewhat, and can't find a real reason or usecase
that contradicts my proposal in any way. All I'm suggesting is that we replace the version
implementation with something that's more flexible, backwards compatible, and can be used for any
known scheme. I'm just asking for usecases where the solution won't work.

Extending the POM to add configuration for custom version schemes is another (though related)
discussion, and can be added later on, though I doubt if it's necessary.

-- Kenney
> 
>>
>> Which part do you disagree with?
>>
>>
>> -- 
>> Richard van der Hoff <ri...@mxtelecom.com>
>> Telephony Gateways Project Manager
>> Tel: +44 (0) 845 666 7778
>> http://www.mxtelecom.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Carlos Sanchez <ca...@apache.org>]

On 12/19/06, Richard van der Hoff <ri...@mxtelecom.com> wrote:
> Carlos Sanchez wrote:
> > the repository has some rules and you have to follow them to be
> > manageable, eg. you name jars artifactId-version.jar and not
> > otherwise. If there are version rules you'd have to follow, and I
> > don't see the problem in having a standardized version convention, as
> >  we have standardized folder names.
>
> As I said before:
>
> > The problem is basically that this simply isn't powerful enough to
> > cover all the various versioning schemes there are in the wild.

4 or more sections will cover almost all the versioning schemas

> > Suggesting forcing everybody to conform to your idea of versioning
> > isn't at all helpful; similarly imposing a complex mapping between
> > upstream and maven versions for a project is unattractive.

projects shouldn't care and will end benefiting from standardization
as they did with folder names. We need to look to other versioning
standards out there (eg. OSGi) instead of inventing a new one.
if a non maven project is 1.0-alpha1 we'd simply use 1/0/alpha/1 and
we can sort the sections

>
> Which part do you disagree with?
>
>
> --
> Richard van der Hoff <ri...@mxtelecom.com>
> Telephony Gateways Project Manager
> Tel: +44 (0) 845 666 7778
> http://www.mxtelecom.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Richard van der Hoff <ri...@mxtelecom.com>]

Carlos Sanchez wrote:
> the repository has some rules and you have to follow them to be 
> manageable, eg. you name jars artifactId-version.jar and not 
> otherwise. If there are version rules you'd have to follow, and I 
> don't see the problem in having a standardized version convention, as
>  we have standardized folder names.

As I said before:

> The problem is basically that this simply isn't powerful enough to
> cover all the various versioning schemes there are in the wild.
> Suggesting forcing everybody to conform to your idea of versioning
> isn't at all helpful; similarly imposing a complex mapping between
> upstream and maven versions for a project is unattractive.

Which part do you disagree with?


-- 
Richard van der Hoff <ri...@mxtelecom.com>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Carlos Sanchez <ca...@apache.org>]

On 12/19/06, Richard van der Hoff <ri...@mxtelecom.com> wrote:
> Carlos Sanchez wrote:
> > and almost all artifacts in repo can be expressed as 4 different
> > alphanumeric sections, so no problem there,
>
> And the ones that can't? We don't care about those? And the ones in
> peoples private repositories?


the repository has some rules and you have to follow them to be
manageable, eg. you name jars artifactId-version.jar and not
otherwise. If there are version rules you'd have to follow, and I
don't see the problem in having a standardized version convention, as
we have standardized folder names.


>
>
> --
> Richard van der Hoff <ri...@mxtelecom.com>
> Telephony Gateways Project Manager
> Tel: +44 (0) 845 666 7778
> http://www.mxtelecom.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Richard van der Hoff <ri...@mxtelecom.com>]

Carlos Sanchez wrote:
> and almost all artifacts in repo can be expressed as 4 different
> alphanumeric sections, so no problem there,

And the ones that can't? We don't care about those? And the ones in 
peoples private repositories?


-- 
Richard van der Hoff <ri...@mxtelecom.com>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Carlos Sanchez <ca...@apache.org>]

On 12/19/06, Richard van der Hoff <ri...@mxtelecom.com> wrote:
> Carlos Sanchez wrote:
> > the other tags that can be reduced, but losing simplicity. Not using
> > attributes also makes the pom verbose and nobody questions that.
>
> They do, actually - it's been discussed here before.

let me rephrase, a more verbose pom was used for easier usability

>
> > 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.
>
> What added features? The ability to compare version numbers? A bit
> fundamental imho.

and almost all artifacts in repo can be expressed as 4 different
alphanumeric sections, so no problem there, i'm just talking about
splitting them in different sections rather than concatenate

>
>
> --
> Richard van der Hoff <ri...@mxtelecom.com>
> Telephony Gateways Project Manager
> Tel: +44 (0) 845 666 7778
> http://www.mxtelecom.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Richard van der Hoff <ri...@mxtelecom.com>]

Carlos Sanchez wrote:
> the other tags that can be reduced, but losing simplicity. Not using
> attributes also makes the pom verbose and nobody questions that.

They do, actually - it's been discussed here before.

> 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.

What added features? The ability to compare version numbers? A bit 
fundamental imho.


-- 
Richard van der Hoff <ri...@mxtelecom.com>
Telephony Gateways Project Manager
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Carlos Sanchez <ca...@apache.org>]

On 12/19/06, Kenney Westerhof <ke...@apache.org> 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 <ke...@apache.org> 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: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Kenney Westerhof <ke...@apache.org>]

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.

> 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.
> 
> For instance
> 
> <version>
>  <major>1</major>
>  <minor>2<minor>
>  <bug>1</bug>
>  <buildnumber>123</buildnumber>
> </version>
> 
> 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.

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 <ke...@apache.org> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Kenney Westerhof <ke...@apache.org>]

ir. ing. Jan Dockx wrote:
> 
> On 19 Dec 2006, at 17:50, Kenney Westerhof wrote:
> 
>> What tool uses those invariant annotations? Looks useful for 
>> application validation.
> 
> ;-) Let's discuss that off-line.

cool, kenney@irc://irc.codehaus.org/#maven

[snip]

>>> <dependency>
>>>     <groupId>...</groupId>
>>>         <artifactId>...<artifactId>
>>>     <version>[versionString]</version>
>>>         <useBestCompatible>true</useBestCompatible>
>>>     <scope>...</scope>
>>> </dependency>
>>
>> What would be in the version string? Usually the first N digits denote 
>> incompatible
>> versions, later ones denote compatibility updates, for instance for 
>> all X: 1.2.X
>> is compatible.
> 
> 
> Well, Maven wouldn't say. That's the point. The version scheme 
> implementation deals with the [versionString], so Maven itself doesn't 
> have to. Of course, most used version scheme's would be found 
> implemented at central, and Maven would have a default (convention over 
> configuration) which will probably be Apaches versioning practice.

Maven doesn't have to say. It should provide sensible default version comparing,
which is present. Next, version ranges should enable users to specify if they want
compatible versions or just the latest release or whatever. It's up to the
person writing the <dependency> tag to get acquainted with the version scheme used on
that project, and decide what kind of version(s) he'd want. 

Your solution works too, but it requires a pom change, and IMHO version ranges already
support this. 
In the case where it's impossible to specify a version range for some particular set of 
versions because the version scheme used by the dependency doesn't allow it, then that's
'not our problem'. May be harsh, but I opt for a generic version scheme implementation that
supports so many version schemes, that you have to try really hard to come up with one
that's so obscure that maven can't handle it.

-- Kenney

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Mark Hobson <ma...@gmail.com>]

On 19/12/06, ir. ing. Jan Dockx <ja...@mac.com> wrote:
> On 19 Dec 2006, at 17:50, Kenney Westerhof wrote:
> > What tool uses those invariant annotations? Looks useful for
> > application validation.
>
> ;-) Let's discuss that off-line.

How comes?  I'd be interested too.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

["ir. ing. Jan Dockx" <ja...@mac.com>]

On 19 Dec 2006, at 17:50, Kenney Westerhof wrote:

> Hi,
>
> ir. ing. Jan Dockx wrote:
>> Well, your schema does follow the Java standard (<http:// 
>> java.sun.com/j2se/1.5.0/docs/guide/versioning/spec/ 
>> versioning2.html#wp89936>). That might be a good default. Maven  
>> could apply a strategy pattern to allow for other versioning  
>> schemes. Only 3 functions are needed, as far as I can see:
>> /**
>>  * @invar ! equals(null);
>>  * @invar ! isCompatible(null);
>>  * @invar ! isBetter(null);
>>  * @invar (forall Version v; equals(v) ==> isCompatible(v));
>>  * @invar (forall Version v; equals(v) ==> ! isBetter(v));
>>  * @invar (forall Version v; isBetter(v) ==> isCompatible(v));
>>  */
>> public interface Version {
>>   boolean isCompatible(Version other);
>>   boolean isBetter(Version other);
>>   boolean equals(Object other);
>> }
>
> What tool uses those invariant annotations? Looks useful for  
> application validation.

;-) Let's discuss that off-line.

>
>> (You can't extend Comparable, because the contract says that you  
>> need to have a result for all combinations of objects of a given  
>> type, and here only compatible versions are comparable).
>> The only thing left for dependency notes in a dependency listing  
>> is then to say whether you want compatible, better versions, or  
>> you want to stay with the exact version denoted. You don't have to  
>> specify here which versions you want, the dependency knows itself  
>> whether or not it is compatible and better than what you require.
>> <dependency>
>>     <groupId>...</groupId>
>>         <artifactId>...<artifactId>
>>     <version>[versionString]</version>
>>         <useBestCompatible>true</useBestCompatible>
>>     <scope>...</scope>
>> </dependency>
>
> What would be in the version string? Usually the first N digits  
> denote incompatible
> versions, later ones denote compatibility updates, for instance for  
> all X: 1.2.X
> is compatible.


Well, Maven wouldn't say. That's the point. The version scheme  
implementation deals with the [versionString], so Maven itself  
doesn't have to. Of course, most used version scheme's would be found  
implemented at central, and Maven would have a default (convention  
over configuration) which will probably be Apaches versioning practice.

>
> Right now maven already handles this using version ranges:  
> [1.2,1.3) indicates 1.2[.0] and
> all other compatible versions (excluding alpha versions).
>
>> The POM of an artifact should than refer to a Version  
>> implementation. So, version implementations should be separate  
>> artifacts themselves.
>> ...
>> <versionScheme>
>>     <groupId>...</groupId>
>>         <artifactId>...<artifactId>
>>     <version>[versionString]</version>
>> </versionScheme>
>> <version>[versionString]</version>
>> ...
>
> Yeah, something like that would be useful - it should define a  
> metadata file
> indicating the version class implementations to use for that  
> artifact. That was one
> other possibility I was considering. It's probably more flexible.
>
>> And the version scheme for version schemes should be fixed by Maven.
>> We probably need a factory too for each version implementation:
>> public interface VersionFactory {
>>   Version parse(String versionString);
>> }
>
> Yup. Or a one arg constructor with string - it'll probably be  
> called using reflection anyway.
>
> -- Kenney
>
>> On 19 Dec 2006, at 11:44, Carlos Sanchez wrote:
>>> Sound like a lot of added complexity that will cause trouble to all
>>> tooling on top of Maven
>>>
>>> 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.
>>>
>>> For instance
>>>
>>> <version>
>>>  <major>1</major>
>>>  <minor>2<minor>
>>>  <bug>1</bug>
>>>  <buildnumber>123</buildnumber>
>>> </version>
>>>
>>> It's gonna be more complex for manual editing but being standard xml
>>> will be easier to implement
>>>
>>> On 12/18/06, Kenney Westerhof <ke...@apache.org> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>> --I could give you my word as a Spaniard.
>>> No good. I've known too many Spaniards.
>>>                             -- The Princess Bride
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Kenney Westerhof <ke...@apache.org>]

Hi,

ir. ing. Jan Dockx wrote:
> Well, your schema does follow the Java standard 
> (<http://java.sun.com/j2se/1.5.0/docs/guide/versioning/spec/versioning2.html#wp89936>). 
> That might be a good default. Maven could apply a strategy pattern to 
> allow for other versioning schemes. Only 3 functions are needed, as far 
> as I can see:
> 
> /**
>  * @invar ! equals(null);
>  * @invar ! isCompatible(null);
>  * @invar ! isBetter(null);
>  * @invar (forall Version v; equals(v) ==> isCompatible(v));
>  * @invar (forall Version v; equals(v) ==> ! isBetter(v));
>  * @invar (forall Version v; isBetter(v) ==> isCompatible(v));
>  */
> public interface Version {
> 
>   boolean isCompatible(Version other);
> 
>   boolean isBetter(Version other);
> 
>   boolean equals(Object other);
> 
> }
> 

What tool uses those invariant annotations? Looks useful for application validation.

> (You can't extend Comparable, because the contract says that you need to 
> have a result for all combinations of objects of a given type, and here 
> only compatible versions are comparable).
> 
> The only thing left for dependency notes in a dependency listing is then 
> to say whether you want compatible, better versions, or you want to stay 
> with the exact version denoted. You don't have to specify here which 
> versions you want, the dependency knows itself whether or not it is 
> compatible and better than what you require.
> 
> <dependency>
>     <groupId>...</groupId>
>         <artifactId>...<artifactId>
>     <version>[versionString]</version>
>         <useBestCompatible>true</useBestCompatible>
>     <scope>...</scope>
> </dependency>

What would be in the version string? Usually the first N digits denote incompatible
versions, later ones denote compatibility updates, for instance for all X: 1.2.X
is compatible.

Right now maven already handles this using version ranges: [1.2,1.3) indicates 1.2[.0] and
all other compatible versions (excluding alpha versions).

> 
> The POM of an artifact should than refer to a Version implementation. 
> So, version implementations should be separate artifacts themselves.
> 
> ...
> <versionScheme>
>     <groupId>...</groupId>
>         <artifactId>...<artifactId>
>     <version>[versionString]</version>
> </versionScheme>
> <version>[versionString]</version>
> ...
> 

Yeah, something like that would be useful - it should define a metadata file
indicating the version class implementations to use for that artifact. That was one
other possibility I was considering. It's probably more flexible.

> And the version scheme for version schemes should be fixed by Maven.
> 
> 
> We probably need a factory too for each version implementation:
> 
> public interface VersionFactory {
> 
>   Version parse(String versionString);
> 
> }

Yup. Or a one arg constructor with string - it'll probably be called using reflection anyway.

-- Kenney

> 
> 
> On 19 Dec 2006, at 11:44, Carlos Sanchez wrote:
> 
>> Sound like a lot of added complexity that will cause trouble to all
>> tooling on top of Maven
>>
>> 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.
>>
>> For instance
>>
>> <version>
>>  <major>1</major>
>>  <minor>2<minor>
>>  <bug>1</bug>
>>  <buildnumber>123</buildnumber>
>> </version>
>>
>> It's gonna be more complex for manual editing but being standard xml
>> will be easier to implement
>>
>> On 12/18/06, Kenney Westerhof <ke...@apache.org> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>> --I could give you my word as a Spaniard.
>> No good. I've known too many Spaniards.
>>                             -- The Princess Bride
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

["ir. ing. Jan Dockx" <ja...@mac.com>]

Well, your schema does follow the Java standard (<http://java.sun.com/ 
j2se/1.5.0/docs/guide/versioning/spec/versioning2.html#wp89936>).  
That might be a good default. Maven could apply a strategy pattern to  
allow for other versioning schemes. Only 3 functions are needed, as  
far as I can see:

/**
  * @invar ! equals(null);
  * @invar ! isCompatible(null);
  * @invar ! isBetter(null);
  * @invar (forall Version v; equals(v) ==> isCompatible(v));
  * @invar (forall Version v; equals(v) ==> ! isBetter(v));
  * @invar (forall Version v; isBetter(v) ==> isCompatible(v));
  */
public interface Version {

   boolean isCompatible(Version other);

   boolean isBetter(Version other);

   boolean equals(Object other);

}

(You can't extend Comparable, because the contract says that you need  
to have a result for all combinations of objects of a given type, and  
here only compatible versions are comparable).

The only thing left for dependency notes in a dependency listing is  
then to say whether you want compatible, better versions, or you want  
to stay with the exact version denoted. You don't have to specify  
here which versions you want, the dependency knows itself whether or  
not it is compatible and better than what you require.

<dependency>
	<groupId>...</groupId>
         <artifactId>...<artifactId>
	<version>[versionString]</version>
         <useBestCompatible>true</useBestCompatible>
	<scope>...</scope>
</dependency>

The POM of an artifact should than refer to a Version implementation.  
So, version implementations should be separate artifacts themselves.

...
<versionScheme>
	<groupId>...</groupId>
         <artifactId>...<artifactId>
	<version>[versionString]</version>
</versionScheme>
<version>[versionString]</version>
...

And the version scheme for version schemes should be fixed by Maven.


We probably need a factory too for each version implementation:

public interface VersionFactory {

   Version parse(String versionString);

}


On 19 Dec 2006, at 11:44, Carlos Sanchez wrote:

> Sound like a lot of added complexity that will cause trouble to all
> tooling on top of Maven
>
> 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.
>
> For instance
>
> <version>
>  <major>1</major>
>  <minor>2<minor>
>  <bug>1</bug>
>  <buildnumber>123</buildnumber>
> </version>
>
> It's gonna be more complex for manual editing but being standard xml
> will be easier to implement
>
> On 12/18/06, Kenney Westerhof <ke...@apache.org> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> -- 
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                             -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Aa...@Globus.ch]

> <version>
>   <major>1</major>
>   <minor>2<minor>
>   <bug>1</bug>
>   <buildnumber>123</buildnumber>
> </version>

It's just as simple to specify a regexp which defines what is allowed as 
the text child for the version element.

Do not break everything up into one element. That's an XML sickness from 
the DTD era (or rather the pre-XSD/Schema era).

Regards,

-- 
Aaron Digulla


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Carlos Sanchez <ca...@apache.org>]

Sound like a lot of added complexity that will cause trouble to all
tooling on top of Maven

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.

For instance

<version>
  <major>1</major>
  <minor>2<minor>
  <bug>1</bug>
  <buildnumber>123</buildnumber>
</version>

It's gonna be more complex for manual editing but being standard xml
will be easier to implement

On 12/18/06, Kenney Westerhof <ke...@apache.org> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Brett Porter <br...@apache.org>]

If it's backwards compatible, then there should be no problem with  
just replacing the current algorithm with this one in 2.1.

I think the other points will certainly need to be addressed before  
any other maven-artifact work.

Cheers,
Brett

On 24/12/2006, at 8:54 AM, Kenney Westerhof wrote:

>
>
> FYI, I've created a Wiki page under the Maven 2.1 design documents  
> describing
> the proposal:
>
> http://docs.codehaus.org/display/MAVEN/Versioning
>
> FWIW,I think '1.0-alpha10' being treated as older than 1.0-alpha2  
> is a bug, and doesn't
> warrant a pom version change.
>
> The only incompatibility, aside from being able to support  
> '1.2.3.4.betaX' and, generally, more
> version schemes, is the consideration of 1.0-xyz being considered  
> newer than 1.0,
> which I've put up for debate. If my proposed behaviour is changed  
> to match the current
> handling, I don't think a pom change is needed (so point B is not  
> necessarily true).
>
> Point A is part of the proposal too, though I feel it's not  
> required at all; the same
> goes for the version conflict resolution which should be pluggable.  
> THough we will
> need to make provisions for this in a new pom model.
>
> As for point C, I agree - we should somehow be able to use  
> different component
> implementations depending on the pom version specified, although  
> this can get pretty
> complicated:
>
> - I say different component versions since I'd hate for the maven  
> code to be full of conditionals
> depending on the pom version;
> - Complication in that you'll get mixed versions in the dependency  
> tree or reactor, and some
> behaviours are not confined to a single pom. I'm sure you can think  
> of some examples.
>
> I've seen that there's a section on this on the wiki, and it needs  
> a lot of work
> (currently just the requirement of loading poms with modelVersion  
> above 4.0.0 is stated,
> although modelVersion and maven behaviour are different things to me).
>
> What's the plan? It seems there's a ton of designing to do before  
> we could incorporate some proposals
> (including mine which is basically finished and ready to go).
>
> -- Kenney
>
> Jason van Zyl wrote:
>> On 22 Dec 06, at 5:07 PM 22 Dec 06, Brett Porter wrote:
>>> At first blush this seems good. I haven't looked in detail.
>>>
>>> We have some key things to put in place first though (not in this  
>>> order).
>>>
>>> a) support for selection of alternate versioning
>>> b) since it's not backwards compatible, we need to use the old  
>>> scheme for v4.0.0 POMs
>>> c) ability to read different versions of POMs.
>>>
>>> The last one is really a blocker to us doing anything in Maven  
>>> 2.1 that might alter behaviour (changes to dependency handling,  
>>> conflict resolution, versioning, lifecycle, ...)
>>>
>> I have a proposal for maven-artifact that I'll work on with Kenney  
>> which will complement his versioning proposal.
>> Jason.
>>> I still need to take a more detailed look at this, but I've  
>>> switched my brain of for the holidays unfortunately :)
>>>
>>> - Brett
>>>
>>> On 19/12/2006, at 9:43 AM, Kenney Westerhof 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Kenney Westerhof <ke...@apache.org>]

FYI, I've created a Wiki page under the Maven 2.1 design documents describing
the proposal:

http://docs.codehaus.org/display/MAVEN/Versioning

FWIW,I think '1.0-alpha10' being treated as older than 1.0-alpha2 is a bug, and doesn't
warrant a pom version change.

The only incompatibility, aside from being able to support '1.2.3.4.betaX' and, generally, more
version schemes, is the consideration of 1.0-xyz being considered newer than 1.0,
which I've put up for debate. If my proposed behaviour is changed to match the current
handling, I don't think a pom change is needed (so point B is not necessarily true).

Point A is part of the proposal too, though I feel it's not required at all; the same
goes for the version conflict resolution which should be pluggable. THough we will
need to make provisions for this in a new pom model.

As for point C, I agree - we should somehow be able to use different component
implementations depending on the pom version specified, although this can get pretty
complicated:

- I say different component versions since I'd hate for the maven code to be full of conditionals
depending on the pom version;
- Complication in that you'll get mixed versions in the dependency tree or reactor, and some
behaviours are not confined to a single pom. I'm sure you can think of some examples.

I've seen that there's a section on this on the wiki, and it needs a lot of work
(currently just the requirement of loading poms with modelVersion above 4.0.0 is stated,
although modelVersion and maven behaviour are different things to me).

What's the plan? It seems there's a ton of designing to do before we could incorporate some proposals
(including mine which is basically finished and ready to go).

-- Kenney

Jason van Zyl wrote:
> 
> On 22 Dec 06, at 5:07 PM 22 Dec 06, Brett Porter wrote:
> 
>> At first blush this seems good. I haven't looked in detail.
>>
>> We have some key things to put in place first though (not in this order).
>>
>> a) support for selection of alternate versioning
>> b) since it's not backwards compatible, we need to use the old scheme 
>> for v4.0.0 POMs
>> c) ability to read different versions of POMs.
>>
>> The last one is really a blocker to us doing anything in Maven 2.1 
>> that might alter behaviour (changes to dependency handling, conflict 
>> resolution, versioning, lifecycle, ...)
>>
> 
> I have a proposal for maven-artifact that I'll work on with Kenney which 
> will complement his versioning proposal.
> 
> Jason.
> 
>> I still need to take a more detailed look at this, but I've switched 
>> my brain of for the holidays unfortunately :)
>>
>> - Brett
>>
>> On 19/12/2006, at 9:43 AM, Kenney Westerhof 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Jason van Zyl <ja...@maven.org>]

On 23 Dec 06, at 5:48 PM 23 Dec 06, Brett Porter wrote:

>
> On 24/12/2006, at 2:34 AM, Jason van Zyl wrote:
>
>>
>> I have a proposal for maven-artifact that I'll work on with Kenney  
>> which will complement his versioning proposal.
>>
>
> How do I get involved? I kind of feel like this is unfinished  
> business for me, so I'd like to participate. I have a bunch of ideas.
>

This is something I plan to discuss on the PMC list as this is the  
first time I have the intersection where a client needs core changes  
that I'm getting paid to make. So starting tomorrow I will start full- 
time over the next three weeks to test, implement changes in maven- 
artifact. I've poked and pushed but tomorrow the real work starts, as  
I go I will pump stuff into the wiki. Based on what the PMC decides  
about vendor branches, which is what this is even though the client  
wants this done in the accepted fashion and would like it to be part  
of the core, and if people like the changes I will put them in. I  
think they are fixes that makes a lot of broken things work but I  
will start updating the wiki at the first opportunity. It will most  
likely come in fast and furious over the next couple of days. If the  
PMC decides it's cool to put in a branch then I'll do that too.

Jason.

> - Brett
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Brett Porter <br...@apache.org>]

On 24/12/2006, at 2:34 AM, Jason van Zyl wrote:

>
> I have a proposal for maven-artifact that I'll work on with Kenney  
> which will complement his versioning proposal.
>

How do I get involved? I kind of feel like this is unfinished  
business for me, so I'd like to participate. I have a bunch of ideas.

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Jason van Zyl <ja...@maven.org>]

On 22 Dec 06, at 5:07 PM 22 Dec 06, Brett Porter wrote:

> At first blush this seems good. I haven't looked in detail.
>
> We have some key things to put in place first though (not in this  
> order).
>
> a) support for selection of alternate versioning
> b) since it's not backwards compatible, we need to use the old  
> scheme for v4.0.0 POMs
> c) ability to read different versions of POMs.
>
> The last one is really a blocker to us doing anything in Maven 2.1  
> that might alter behaviour (changes to dependency handling,  
> conflict resolution, versioning, lifecycle, ...)
>

I have a proposal for maven-artifact that I'll work on with Kenney  
which will complement his versioning proposal.

Jason.

> I still need to take a more detailed look at this, but I've  
> switched my brain of for the holidays unfortunately :)
>
> - Brett
>
> On 19/12/2006, at 9:43 AM, Kenney Westerhof 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Brett Porter <br...@apache.org>]

At first blush this seems good. I haven't looked in detail.

We have some key things to put in place first though (not in this  
order).

a) support for selection of alternate versioning
b) since it's not backwards compatible, we need to use the old scheme  
for v4.0.0 POMs
c) ability to read different versions of POMs.

The last one is really a blocker to us doing anything in Maven 2.1  
that might alter behaviour (changes to dependency handling, conflict  
resolution, versioning, lifecycle, ...)

I still need to take a more detailed look at this, but I've switched  
my brain of for the holidays unfortunately :)

- Brett

On 19/12/2006, at 9:43 AM, Kenney Westerhof 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Eric Redmond <er...@gmail.com>]

On 12/20/06, Kenney Westerhof <ke...@apache.org> wrote:
>
>
>
> John Casey wrote:
> > Hmm, okay. I'm just going to reply at the top level, since I'm going to
> > make
> > a few general comments:
> >
> > 1. I really like this explanation/algorithm/implementation. It seems to
> > take
> > into account a LOT of permutations, and even more importantly, it
> specifies
> > a specification that we can write down in whatever form...and then
> extend,
> > if necessary.
>
> Indeed.
>
> > 1a. I think the version scheme should be specified in something like
> > EBNF so
> > people can write compliant lexers/parsers in whatever language they
> want.
>
> Hm, good idea, except most grammars use other syntax for EBNF or only
> support BNF.
> If we had a pluggable 'version' component, the implementation would take
> care of
> parsing/ordering, and we didn't need to specify the version in EBNF, but
> just some metadata in the version jar or the project's homepage.


I script almost everything in Ruby, not Java. Having some sort of normal
form would be immensly useful, if for nothing else but posterity.

> 1b. For Java, I think this version-parser needs to be separated from
> > maven-artifact, and available for reuse by itself from other APIs
> (thinking
> > plugins here, among other things).
>
> Yes, good idea.
>
> > 2. While I do like the following algorithm, I think it needs to be the
> > DEFAULT version scheme, and we need to make room for others to plug in
> > their
> > own. We can spend years trying to incorporate all possible version
> schemes
> > in a single parser, but IMO the complexity involved with encompassing
> every
> > version in a single parser just isn't worth it.
>
> The 1b would support this pluggability. But agreed, we can't support all
> version schemes, but this comes close IMHO.
>
> > I think we need to come up with an API for other implementations of a
> > VersionScheme. This probably isn't going to be a single interface, for
> the
> > purposes of separating behaviors...but we should include in this API
> > everything that needs to be known about a version in order to:
> >
> > * resolve conflicts
> >
> > * compute range boundaries
> >
> > * order versions
> >
> > * determine what version strings denote snapshot behavior (multiple
> > releases
> > of a single version of an RPM can act this way, for instance)
>
> So we can handle versions that don't have the SNAPSHOT keyword in them
> as snapshots too? That would be cool - for instance, some projects use
> '-dev'
> to denote snapshots.


Ugh. While I like the idea of flexibility, this takes it too far. I like
being able to look at any Maven project in the world and know, by looking at
it, that -SNAPSHOT means "in development", and not have to guess if some
special project is using -dev. This should be immutable, imo.

> * whatever else.
>
> Right. ;)
>
> The biggest difference in the API would be that there's no
> 'getMajor|MinorVersion' anymore
> since we can't know if the scheme has that or even names it like that.


You could reasonably assume that the first element is major, second is
minor, and then - whatever the cardinality - the rest accessible by index.

> 2a. Version schemes should be standardized, and available to a build using
> > artifact resolution and the default maven version scheme (you have to
> > make a
> > stand somewhere :). IMO, specifying a regex or some other free-form
> version
> > scheme directly inside a POM is neither sufficient nor reusable enough;
> if
> > people need a custom version scheme, they need to encode it somewhere
> > that's
> > permanent.
>
> Agreed. Except that I'd like to split off the discussion about version
> specifications.
> We've got 3 major points of discussion here:
>
> - replace the default implementation to be more flexible (my original
> intent)
> - make version schemes pluggable/configurable, for instance by specifying
> a version lib implementation
> - define something default to specify version schemes, like regex/EBNF/xsd
>
> > This is just my opinion, but I've been working outside the bounds of
> > 'normal' Jar/Maven versioning quite a bit over the last year and a half,
> > and
> > I definitely think we need to keep it in mind that the only truly
> > sufficient
> > model of reality is reality itself...which means a lot of complexity.
> >
> > I think that's about it; I'll keep thinking, though.
>
> Thanks!
>
> More details on RPM versioning would be welcome; I'm only familiar with
> Debian versioning
> which would, AFAIK, be supported by my proposal.
>
> -- Kenney
>
> >
> > Cheers,
> >
> > -john
> >
> >
> > On 12/18/06, Kenney Westerhof <ke...@apache.org> 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: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
Eric Redmond
http://codehaus.org/~eredmond

Re: versioning

[John Casey <ca...@gmail.com>]

Well, I'm certainly not an expert on the RPM versioning stuff, yet. I'll be
studying it intensely in the near future, and then I'll put something
together (for my own notes, if nothing else...so I'll be happy to share).

As far as splitting the discussion, I agree, except for one point: we need
to be thinking about the way forward when we replace/fix the existing
implementation, so we can start factoring the different parts out into the
appropriate classes and interfaces...which would eventually split into a
separate API (sounds a bit like biological cell division, but there you are
:-).

-john

On 12/20/06, Kenney Westerhof <ke...@apache.org> wrote:
>
>
>
> John Casey wrote:
> > Hmm, okay. I'm just going to reply at the top level, since I'm going to
> > make
> > a few general comments:
> >
> > 1. I really like this explanation/algorithm/implementation. It seems to
> > take
> > into account a LOT of permutations, and even more importantly, it
> specifies
> > a specification that we can write down in whatever form...and then
> extend,
> > if necessary.
>
> Indeed.
>
> > 1a. I think the version scheme should be specified in something like
> > EBNF so
> > people can write compliant lexers/parsers in whatever language they
> want.
>
> Hm, good idea, except most grammars use other syntax for EBNF or only
> support BNF.
> If we had a pluggable 'version' component, the implementation would take
> care of
> parsing/ordering, and we didn't need to specify the version in EBNF, but
> just some metadata in the version jar or the project's homepage.
>
> > 1b. For Java, I think this version-parser needs to be separated from
> > maven-artifact, and available for reuse by itself from other APIs
> (thinking
> > plugins here, among other things).
>
> Yes, good idea.
>
> > 2. While I do like the following algorithm, I think it needs to be the
> > DEFAULT version scheme, and we need to make room for others to plug in
> > their
> > own. We can spend years trying to incorporate all possible version
> schemes
> > in a single parser, but IMO the complexity involved with encompassing
> every
> > version in a single parser just isn't worth it.
>
> The 1b would support this pluggability. But agreed, we can't support all
> version schemes, but this comes close IMHO.
>
> > I think we need to come up with an API for other implementations of a
> > VersionScheme. This probably isn't going to be a single interface, for
> the
> > purposes of separating behaviors...but we should include in this API
> > everything that needs to be known about a version in order to:
> >
> > * resolve conflicts
> >
> > * compute range boundaries
> >
> > * order versions
> >
> > * determine what version strings denote snapshot behavior (multiple
> > releases
> > of a single version of an RPM can act this way, for instance)
>
> So we can handle versions that don't have the SNAPSHOT keyword in them
> as snapshots too? That would be cool - for instance, some projects use
> '-dev'
> to denote snapshots.
>
> >
> > * whatever else.
>
> Right. ;)
>
> The biggest difference in the API would be that there's no
> 'getMajor|MinorVersion' anymore
> since we can't know if the scheme has that or even names it like that.
>
> > 2a. Version schemes should be standardized, and available to a build
> using
> > artifact resolution and the default maven version scheme (you have to
> > make a
> > stand somewhere :). IMO, specifying a regex or some other free-form
> version
> > scheme directly inside a POM is neither sufficient nor reusable enough;
> if
> > people need a custom version scheme, they need to encode it somewhere
> > that's
> > permanent.
>
> Agreed. Except that I'd like to split off the discussion about version
> specifications.
> We've got 3 major points of discussion here:
>
> - replace the default implementation to be more flexible (my original
> intent)
> - make version schemes pluggable/configurable, for instance by specifying
> a version lib implementation
> - define something default to specify version schemes, like regex/EBNF/xsd
>
> > This is just my opinion, but I've been working outside the bounds of
> > 'normal' Jar/Maven versioning quite a bit over the last year and a half,
> > and
> > I definitely think we need to keep it in mind that the only truly
> > sufficient
> > model of reality is reality itself...which means a lot of complexity.
> >
> > I think that's about it; I'll keep thinking, though.
>
> Thanks!
>
> More details on RPM versioning would be welcome; I'm only familiar with
> Debian versioning
> which would, AFAIK, be supported by my proposal.
>
> -- Kenney
>
> >
> > Cheers,
> >
> > -john
> >
> >
> > On 12/18/06, Kenney Westerhof <ke...@apache.org> 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: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: versioning

[Kenney Westerhof <ke...@apache.org>]

John Casey wrote:
> Hmm, okay. I'm just going to reply at the top level, since I'm going to 
> make
> a few general comments:
> 
> 1. I really like this explanation/algorithm/implementation. It seems to 
> take
> into account a LOT of permutations, and even more importantly, it specifies
> a specification that we can write down in whatever form...and then extend,
> if necessary.

Indeed.

> 1a. I think the version scheme should be specified in something like 
> EBNF so
> people can write compliant lexers/parsers in whatever language they want.

Hm, good idea, except most grammars use other syntax for EBNF or only support BNF.
If we had a pluggable 'version' component, the implementation would take care of
parsing/ordering, and we didn't need to specify the version in EBNF, but
just some metadata in the version jar or the project's homepage.

> 1b. For Java, I think this version-parser needs to be separated from
> maven-artifact, and available for reuse by itself from other APIs (thinking
> plugins here, among other things).

Yes, good idea.

> 2. While I do like the following algorithm, I think it needs to be the
> DEFAULT version scheme, and we need to make room for others to plug in 
> their
> own. We can spend years trying to incorporate all possible version schemes
> in a single parser, but IMO the complexity involved with encompassing every
> version in a single parser just isn't worth it.

The 1b would support this pluggability. But agreed, we can't support all
version schemes, but this comes close IMHO. 

> I think we need to come up with an API for other implementations of a
> VersionScheme. This probably isn't going to be a single interface, for the
> purposes of separating behaviors...but we should include in this API
> everything that needs to be known about a version in order to:
> 
> * resolve conflicts
> 
> * compute range boundaries
> 
> * order versions
> 
> * determine what version strings denote snapshot behavior (multiple 
> releases
> of a single version of an RPM can act this way, for instance)

So we can handle versions that don't have the SNAPSHOT keyword in them 
as snapshots too? That would be cool - for instance, some projects use '-dev' 
to denote snapshots.

> 
> * whatever else.

Right. ;)

The biggest difference in the API would be that there's no 'getMajor|MinorVersion' anymore
since we can't know if the scheme has that or even names it like that.

> 2a. Version schemes should be standardized, and available to a build using
> artifact resolution and the default maven version scheme (you have to 
> make a
> stand somewhere :). IMO, specifying a regex or some other free-form version
> scheme directly inside a POM is neither sufficient nor reusable enough; if
> people need a custom version scheme, they need to encode it somewhere 
> that's
> permanent.

Agreed. Except that I'd like to split off the discussion about version specifications.
We've got 3 major points of discussion here:

- replace the default implementation to be more flexible (my original intent)
- make version schemes pluggable/configurable, for instance by specifying a version lib implementation
- define something default to specify version schemes, like regex/EBNF/xsd

> This is just my opinion, but I've been working outside the bounds of
> 'normal' Jar/Maven versioning quite a bit over the last year and a half, 
> and
> I definitely think we need to keep it in mind that the only truly 
> sufficient
> model of reality is reality itself...which means a lot of complexity.
> 
> I think that's about it; I'll keep thinking, though.

Thanks!

More details on RPM versioning would be welcome; I'm only familiar with Debian versioning
which would, AFAIK, be supported by my proposal.

-- Kenney

> 
> Cheers,
> 
> -john
> 
> 
> On 12/18/06, Kenney Westerhof <ke...@apache.org> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[John Casey <ca...@gmail.com>]

Hmm, okay. I'm just going to reply at the top level, since I'm going to make
a few general comments:

1. I really like this explanation/algorithm/implementation. It seems to take
into account a LOT of permutations, and even more importantly, it specifies
a specification that we can write down in whatever form...and then extend,
if necessary.

1a. I think the version scheme should be specified in something like EBNF so
people can write compliant lexers/parsers in whatever language they want.

1b. For Java, I think this version-parser needs to be separated from
maven-artifact, and available for reuse by itself from other APIs (thinking
plugins here, among other things).

2. While I do like the following algorithm, I think it needs to be the
DEFAULT version scheme, and we need to make room for others to plug in their
own. We can spend years trying to incorporate all possible version schemes
in a single parser, but IMO the complexity involved with encompassing every
version in a single parser just isn't worth it.

I think we need to come up with an API for other implementations of a
VersionScheme. This probably isn't going to be a single interface, for the
purposes of separating behaviors...but we should include in this API
everything that needs to be known about a version in order to:

* resolve conflicts

* compute range boundaries

* order versions

* determine what version strings denote snapshot behavior (multiple releases
of a single version of an RPM can act this way, for instance)

* whatever else.

2a. Version schemes should be standardized, and available to a build using
artifact resolution and the default maven version scheme (you have to make a
stand somewhere :). IMO, specifying a regex or some other free-form version
scheme directly inside a POM is neither sufficient nor reusable enough; if
people need a custom version scheme, they need to encode it somewhere that's
permanent.

This is just my opinion, but I've been working outside the bounds of
'normal' Jar/Maven versioning quite a bit over the last year and a half, and
I definitely think we need to keep it in mind that the only truly sufficient
model of reality is reality itself...which means a lot of complexity.

I think that's about it; I'll keep thinking, though.

Cheers,

-john


On 12/18/06, Kenney Westerhof <ke...@apache.org> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: versioning

[Stephane Nicoll <st...@gmail.com>]

On 12/19/06, Jason Dillon <ja...@planet57.com> wrote:
> I've seen projects switch back and forth... depends on who is in
> power at the time and what style they like.  So it would be best if
> mvn would be able comprehend:
>
>      1.0alpha2 < 1.0-alpha-3


I disagree. I don't think it will help maven users if we start
implementing algorithms like this. Why don't we describe the standard
way of specifying a version number? The examples kenney had provided
in his previous email sound a good start to me.

If one want to use another version numbering (such as your example
above) too bad. Now at least he would be aware that version comparison
might not work. We can't predit all scenario anyway.

WDYT?

Stéphane

>
> --jason
>
>
> On Dec 18, 2006, at 3:41 PM, Barrie Treloar wrote:
>
> >> - 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))
> >
> > The edge cases around the examples like 1.0alpha2 and 1.0-alpha-2 are
> > bit beyond how I would use things so I can't really comment.  However
> > I would expect a project to be self consistent so it doesn't really
> > matter if 1.0alpha2 is newer than 1.0-alpha-2, just as long as
> > 1.0alpha2 < 1.0alpha3 and 1.0-alpha-2 < 1.0-alpha-3 which the rules
> > cater for.
> >
> > Everything else seems reasonable and the examples appear to make sense
> > and parse the way I would expect things to work.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Kenney Westerhof <ke...@apache.org>]

Aaron.Digulla@Globus.ch wrote:
> Jason Dillon <ja...@gmail.com> schrieb am 19.12.2006 01:26:54:
> 
>> I've seen projects switch back and forth... depends on who is in 
>> power at the time and what style they like.  So it would be best if 
>> mvn would be able comprehend:
> 
> Since versions are such an important information in Maven, Maven should 
> refuse version numbers which aren't easily comparable.
> 
> How about forcing the contents of the version element in the POM to 1-3 
> digits, separated by dots? That would "help" people who can't decide.
> 
> After that, you can add something with "-" which maven will just 
> string-compare (so alpha10 comes between alpha1 and alpha2).

That's unacceptable, alpha1 < alpha2 < alpha10. 
We don't want to force versioning schemes on projects; that way you can never package Jboss and Eclipse
jars AND be compatible with all the versions out there already.

> 
> Regards,
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Max Bowsher <ma...@mxtelecom.com>]

Aaron.Digulla@Globus.ch wrote:
> After that, you can add something with "-" which maven will just 
> string-compare (so alpha10 comes between alpha1 and alpha2).

Not true, actually. Maven actually has some weird extra logic that kicks
in when one string component is a prefix of the other, such that actually:

   alpha10 < alpha1 < alpha2

Yes, that's bizarre. But it is what it actually does.


Max.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Kenney Westerhof <ke...@apache.org>]

My proposal would solve that: <spec-version>-<impl-version>,
for instance (1.0-3.2) would work just fine. In this case spec versions
take precedence over impl versions, but that's generally what you want anyway.

-- kenney

ir. ing. Jan Dockx wrote:
> Ah. Well. Most libraries (think Jakarta commons) have a spec side and an 
> implementation side. According to the spec, we would need something like 
> 1.2.3-4567. The spec suggests, but does not limit to, a build number for 
> the implementation identification. There is no problem with the 
> major.minor.micro scheme for the spec version, but an overly restrictive 
> Maven standard might rule out having 2 separate parts. I just wanted to 
> say that Maven should look out for that (I do know that most important 
> libs in the wild don't follow the standard, but that's something 
> different -- eclipse is a bit cleaner than Apache in that respect).
> 
> 
> On 19 Dec 2006, at 10:48, Tom Huybrechts wrote:
> 
>> From the spec:
>>
>> A version string is a series of positive numbers separated by periods.
>> The numbers are compared component by component from left to right. If
>> any number is greater than the corresponding number of the supplied
>> string the method returns true. If the number is less than it returns
>> false. If the corresponding numbers are equal the next number is
>> examined.
>>
>> That shouldn't be a problem...
>>
>>
>> On 12/19/06, ir. ing. Jan Dockx <ja...@mac.com> wrote:
>>> I believe that Maven version number support should at least make it
>>> possible to apply the specification / implementation version
>>> numbering scheme that is part of the Java standard (<http://
>>> java.sun.com/j2se/1.5.0/docs/guide/versioning/spec/
>>> versioning2.html#wp89936>).
>>>
>>>
>>>
>>>
>>> On 19 Dec 2006, at 9:33, Aaron.Digulla@Globus.ch wrote:
>>>
>>> > Jason Dillon <ja...@gmail.com> schrieb am 19.12.2006 01:26:54:
>>> >
>>> >> I've seen projects switch back and forth... depends on who is in
>>> >> power at the time and what style they like.  So it would be best if
>>> >> mvn would be able comprehend:
>>> >
>>> > Since versions are such an important information in Maven, Maven
>>> > should
>>> > refuse version numbers which aren't easily comparable.
>>> >
>>> > How about forcing the contents of the version element in the POM to
>>> > 1-3
>>> > digits, separated by dots? That would "help" people who can't decide.
>>> >
>>> > After that, you can add something with "-" which maven will just
>>> > string-compare (so alpha10 comes between alpha1 and alpha2).
>>> >
>>> > Regards,
>>> >
>>> > --
>>> > Aaron Digulla
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> > For additional commands, e-mail: dev-help@maven.apache.org
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

["ir. ing. Jan Dockx" <ja...@mac.com>]

Ah. Well. Most libraries (think Jakarta commons) have a spec side and  
an implementation side. According to the spec, we would need  
something like 1.2.3-4567. The spec suggests, but does not limit to,  
a build number for the implementation identification. There is no  
problem with the major.minor.micro scheme for the spec version, but  
an overly restrictive Maven standard might rule out having 2 separate  
parts. I just wanted to say that Maven should look out for that (I do  
know that most important libs in the wild don't follow the standard,  
but that's something different -- eclipse is a bit cleaner than  
Apache in that respect).


On 19 Dec 2006, at 10:48, Tom Huybrechts wrote:

> From the spec:
>
> A version string is a series of positive numbers separated by periods.
> The numbers are compared component by component from left to right. If
> any number is greater than the corresponding number of the supplied
> string the method returns true. If the number is less than it returns
> false. If the corresponding numbers are equal the next number is
> examined.
>
> That shouldn't be a problem...
>
>
> On 12/19/06, ir. ing. Jan Dockx <ja...@mac.com> wrote:
>> I believe that Maven version number support should at least make it
>> possible to apply the specification / implementation version
>> numbering scheme that is part of the Java standard (<http://
>> java.sun.com/j2se/1.5.0/docs/guide/versioning/spec/
>> versioning2.html#wp89936>).
>>
>>
>>
>>
>> On 19 Dec 2006, at 9:33, Aaron.Digulla@Globus.ch wrote:
>>
>> > Jason Dillon <ja...@gmail.com> schrieb am 19.12.2006  
>> 01:26:54:
>> >
>> >> I've seen projects switch back and forth... depends on who is in
>> >> power at the time and what style they like.  So it would be  
>> best if
>> >> mvn would be able comprehend:
>> >
>> > Since versions are such an important information in Maven, Maven
>> > should
>> > refuse version numbers which aren't easily comparable.
>> >
>> > How about forcing the contents of the version element in the POM to
>> > 1-3
>> > digits, separated by dots? That would "help" people who can't  
>> decide.
>> >
>> > After that, you can add something with "-" which maven will just
>> > string-compare (so alpha10 comes between alpha1 and alpha2).
>> >
>> > Regards,
>> >
>> > --
>> > Aaron Digulla
>> >
>> >  
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Tom Huybrechts <to...@gmail.com>]

>From the spec:

A version string is a series of positive numbers separated by periods.
The numbers are compared component by component from left to right. If
any number is greater than the corresponding number of the supplied
string the method returns true. If the number is less than it returns
false. If the corresponding numbers are equal the next number is
examined.

That shouldn't be a problem...


On 12/19/06, ir. ing. Jan Dockx <ja...@mac.com> wrote:
> I believe that Maven version number support should at least make it
> possible to apply the specification / implementation version
> numbering scheme that is part of the Java standard (<http://
> java.sun.com/j2se/1.5.0/docs/guide/versioning/spec/
> versioning2.html#wp89936>).
>
>
>
>
> On 19 Dec 2006, at 9:33, Aaron.Digulla@Globus.ch wrote:
>
> > Jason Dillon <ja...@gmail.com> schrieb am 19.12.2006 01:26:54:
> >
> >> I've seen projects switch back and forth... depends on who is in
> >> power at the time and what style they like.  So it would be best if
> >> mvn would be able comprehend:
> >
> > Since versions are such an important information in Maven, Maven
> > should
> > refuse version numbers which aren't easily comparable.
> >
> > How about forcing the contents of the version element in the POM to
> > 1-3
> > digits, separated by dots? That would "help" people who can't decide.
> >
> > After that, you can add something with "-" which maven will just
> > string-compare (so alpha10 comes between alpha1 and alpha2).
> >
> > Regards,
> >
> > --
> > Aaron Digulla
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

["ir. ing. Jan Dockx" <ja...@mac.com>]

I believe that Maven version number support should at least make it  
possible to apply the specification / implementation version  
numbering scheme that is part of the Java standard (<http:// 
java.sun.com/j2se/1.5.0/docs/guide/versioning/spec/ 
versioning2.html#wp89936>).




On 19 Dec 2006, at 9:33, Aaron.Digulla@Globus.ch wrote:

> Jason Dillon <ja...@gmail.com> schrieb am 19.12.2006 01:26:54:
>
>> I've seen projects switch back and forth... depends on who is in
>> power at the time and what style they like.  So it would be best if
>> mvn would be able comprehend:
>
> Since versions are such an important information in Maven, Maven  
> should
> refuse version numbers which aren't easily comparable.
>
> How about forcing the contents of the version element in the POM to  
> 1-3
> digits, separated by dots? That would "help" people who can't decide.
>
> After that, you can add something with "-" which maven will just
> string-compare (so alpha10 comes between alpha1 and alpha2).
>
> Regards,
>
> -- 
> Aaron Digulla
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Aa...@Globus.ch]

Jason Dillon <ja...@gmail.com> schrieb am 19.12.2006 01:26:54:

> I've seen projects switch back and forth... depends on who is in 
> power at the time and what style they like.  So it would be best if 
> mvn would be able comprehend:

Since versions are such an important information in Maven, Maven should 
refuse version numbers which aren't easily comparable.

How about forcing the contents of the version element in the POM to 1-3 
digits, separated by dots? That would "help" people who can't decide.

After that, you can add something with "-" which maven will just 
string-compare (so alpha10 comes between alpha1 and alpha2).

Regards,

-- 
Aaron Digulla

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Jason Dillon <ja...@planet57.com>]

I've seen projects switch back and forth... depends on who is in  
power at the time and what style they like.  So it would be best if  
mvn would be able comprehend:

     1.0alpha2 < 1.0-alpha-3

--jason


On Dec 18, 2006, at 3:41 PM, Barrie Treloar wrote:

>> - 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))
>
> The edge cases around the examples like 1.0alpha2 and 1.0-alpha-2 are
> bit beyond how I would use things so I can't really comment.  However
> I would expect a project to be self consistent so it doesn't really
> matter if 1.0alpha2 is newer than 1.0-alpha-2, just as long as
> 1.0alpha2 < 1.0alpha3 and 1.0-alpha-2 < 1.0-alpha-3 which the rules  
> cater for.
>
> Everything else seems reasonable and the examples appear to make sense
> and parse the way I would expect things to work.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Barrie Treloar <ba...@gmail.com>]

> - 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))

The edge cases around the examples like 1.0alpha2 and 1.0-alpha-2 are
bit beyond how I would use things so I can't really comment.  However
I would expect a project to be self consistent so it doesn't really
matter if 1.0alpha2 is newer than 1.0-alpha-2, just as long as
1.0alpha2 < 1.0alpha3 and 1.0-alpha-2 < 1.0-alpha-3 which the rules cater for.

Everything else seems reasonable and the examples appear to make sense
and parse the way I would expect things to work.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Max Bowsher <ma...@mxtelecom.com>]

Barrie Treloar wrote:
>> 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.
> 
> To quote BBWM page 60: "It is intended that the qualifier indicates a
> version
> prior to release" thus
>   2.0.1-xyz < 2.0.1
> is correct.
> The -INTERNAL was always meant to be a qualifier.
> Thus:
>  2.0-SNAPSHOT < 2.0-INTERNAL < 2.0

Except, that's not have the Maven 2.0.4 code treats them. It does:

  2.0-INTERNAL < 2.0-SNAPSHOT < 2.0

i.e. the qualifiers are compared lexicographically, and 'I' < 'S'.

Max.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: versioning

[Barrie Treloar <ba...@gmail.com>]

> 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.

To quote BBWM page 60: "It is intended that the qualifier indicates a version
prior to release" thus
   2.0.1-xyz < 2.0.1
is correct.
The -INTERNAL was always meant to be a qualifier.
Thus:
  2.0-SNAPSHOT < 2.0-INTERNAL < 2.0

The wiki page was attempting to create an internal release of a
snapshot and it should be obsoleted by an official release.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org