Alternative Version implementation

[Paul Benedict]

David, I accidentally missed something first time around. I am happy Neil
pointed it out (thank you). This is actually the order I was expecting. I
am treating numbers as numbers, with more precision being greater in the
collation.

 1
 1.0
 1.00
 1.000
 1.01
 1.001
 1.010
 1.011
 1.100
 1.101
 1.110
 1.111
 1.1
 1.10
 1.11


Cheers,
Paul

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

> Thanks David, I should have awaited your reply before responding to Paul.
> See that email for more specifics on OSGi versions.
>
> I wasn’t implying anything about agreement with Remi Forax or anybody
> else. In this case, my question was really just a question. However I am
> skeptical about the practical feasibility of creating a version scheme that
> can bring together all the existing practices.
>
> I am also very concerned with your the suggested collation order in which
> 1.1 sorts before 1.00. This is subjective of course, but I find it highly
> counter-intuitive. If the segment looks like a number then it should act
> like a number, unless all segments are explicitly defined as strings with
> alphanumeric sorting.
>
>
> Neil
>
>
> > On 23 Mar 2016, at 20:23, David M. Lloyd <david.lloyd at redhat.com> wrote:
> >
> > The OSGi specification allows (from what I can tell) arbitrary strings
> for the last segment and that is definitely incompatible with the notion of
> these more general version rules... this is the only difference I can find
> though, and many practical examples of OSGi versions should continue to
> work, which at least yields the possibility of moving forward.  Are there
> additional scenarios you can identify?
> >
> > Maven on the other hand does not really have a specification, so I just
> referred to of existing examples and they seem to function as expected.
> >
> > The work I'm doing is intended as something of a bridge between what is
> in place now (a structure which is designed for use in the JDK and which
> implies a strict syntactical and semantic format which is incompatible with
> a very large number of existing schemes and version numbers) and a way to
> allow each layer to impose its own policy.  But I think what you are
> implying is that you share my interpretation of Rémi Forax's opinion that a
> plain string is a better version identifier, with no sorting/comparison or
> validation logic, putting 100% of the responsibility for interpretation and
> validation of the version string to the layer which defines the module.  Is
> my understanding of your position correct?
> >
> > On 03/23/2016 03:01 PM, Neil Bartlett (Paremus) 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
> >>>>
> >>
> >
> > --
> > - DML
>
>