Alternative Version implementation

[David M. Lloyd]

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