Alternative Version implementation

[David M. Lloyd]

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