Alternative Version implementation

[Neil Bartlett (Paremus)]

Hi Paul and David,

You may consider this collation order intuitive, but it’s clearly incompatible with existing version systems; in particular I’m thinking of those used in OSGi and Maven.

I really don’t know to what extent this matters, as it was my understanding that JSR 376 would not define versioning of modules and that this are would be left to the discretion of external tools such as build systems. David can you explain the work you are doing in this context?

Regards,
Neil


> On 23 Mar 2016, at 18:53, Paul Benedict <pbenedict at apache.org> wrote:
> 
> For any of the EG members observing this list,
> 
> I find David's collating order acceptable and expected. I am not privy to
> Reiner's particular discussion, but it is my opinion that 1.0 should
> precede 1.0.0. Although both are numerically equal, one is more precise --
> ambiguity should be first, precision last. I don't find this to be any
> different than the alphanumerical nature of a phone book where A would
> precede AA. That's not a perfect analogy but it gets my point across.
> 
> Cheers,
> Paul
> 
> On Wed, Mar 23, 2016 at 1:46 PM, David M. Lloyd <david.lloyd at redhat.com>
> wrote:
> 
>> On 03/23/2016 09:20 AM, David M. Lloyd wrote:
>> 
>>> I've gone ahead and written a new Version implementation that implements
>>> the rules I've described.  It seems to work OK though I am having a hard
>>> time running all tests locally due to some environmental problem that
>>> I'm still working on, so I don't have a webrev yet.  But I do have a
>>> diff that can be examined (and commented upon) at [1].
>>> 
>> 
>> One oddity that springs up relating to numeric versions when not
>> normalizing the version string in any way is that version segments leading
>> zeros parse and sort strangely.  After fiddling around with various
>> approaches, currently I've settled on this order:
>> 
>> 1
>> 1.0
>> 1.1
>> 1.00
>> 1.01
>> 1.10
>> 1.11
>> 1.000
>> 1.001
>> 1.010
>> 1.011
>> 1.100
>> 1.101
>> 1.110
>> 1.111
>> 
>> Wherein versions are sorted for length first, then for value.  However
>> that might be counter-intuitive if your expectation is that (for example)
>> 1.0 is equal to 1.00 or at least sorts immediately before or after it.  A
>> good case could be made that versions should be normalized to strip leading
>> zeros, and I believe the previous implementation did this (either
>> intentionally or unintentionally) as an implementation side-effect.  The
>> downside of normalization is the extra work and extra String being produced
>> as a result.
>> 
>> A third option would be to reject version segments with leading zeros,
>> which prevents the problem from coming up and also avoids the extra copy
>> work, making the "number" production look like:
>> 
>>   number = ? Unicode decimal digit with values 1-9 ? { ? Unicode decimal
>> digit ? }
>> 
>> Any thoughts on this would be appreciated.
>> --
>> - DML
>>