Alternative Version implementation

[Paul Benedict]

Neil, when you say "In OSGi, version 1 and 1.0 and 1.0.0 are strictly
identical", I don't disagree. You can be numerically equivalent but
collated different. You can either leave the collation undefined or define
some sort of ordering. David chose the latter. Are we maybe talking pass
each other on equivalency vs. collation?

Cheers,
Paul

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

> The incompatibility with OSGi is easy enough to illustrate — Maven less so
> because, as David says, Maven versions are chronically underspecified. In
> OSGi, version 1 and 1.0 and 1.0.0 are strictly identical, with the former
> two being nothing more than abbreviations for the latter. Also David’s
> scheme for implicit separators when transitioning between numeric and
> alphabet characters does not work with OSGi’s qualifier segment, which is a
> single alphanumeric (plus hyphen and underscore) string that is collated
> with String.compare().
>
> Again, I’m struggling to see the motivation. I believe that a universal
> scheme is impossible — it’s a circle that can’t be squared, especially when
> you try to encompass the versions used by Java releases like “8u66”. So if
> it’s not universal and it’s not to be adopted by JSR 376, what is the
> intended purpose?
>
> Neil
>
> On 23 Mar 2016, at 20:10, Paul Benedict <pbenedict at apache.org> wrote:
>
> 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
>> >>
>>
>>
>
>