Alternative Version implementation

[Paul Benedict]

Neil, I believe you're right regarding how JSR 376 will not define
versions. David can speak for himself, but I didn't get the impression he
is proposing a "de facto" way of what a version scheme is. His class just
encompasses the many versioning schemes out in the wild so they can be
parsed and inspected by a single class. I don't see any incompatibility
with OSGi and Maven here, per se, since their schemes is just one of many.
David's code does give a universal way to collate with these schemes, which
I find appealing.

Cheers,
Paul

On Wed, Mar 23, 2016 at 3:01 PM, Neil Bartlett (Paremus) <
neil.bartlett at paremus.com> wrote:

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