Alternative Version implementation

[Paul Benedict]

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
>