Alternative Version implementation

[David M. Lloyd]

Understood, thanks for the feedback.  Yes it does seem like it would be 
impossible to fully reconcile the two problems of OSGi version 
abbreviations and that open-ended final segment.

As for the collation order - I agree that it is not great.  I just 
finished (locally) a tree which simply forbids leading zeros; this is 
also appealing for its simplicity but I'm afraid might interfere with a 
lot more common practice version schemes (just google "version 1.001" to 
see what I mean).

I'll follow up on that on Paul's thread.

On 03/23/2016 03:44 PM, Neil Bartlett (Paremus) 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
>

-- 
- DML