Missing issue: Version string format

[David M. Lloyd]

I'd be okay with that personally.  It would certainly be less code.  :)

Having a general version syntax and collation system is generally useful 
but it's a bit more of an abstract sort of usefulness.

On 03/21/2016 07:30 PM, Remi Forax wrote:
> Hi David,
> maybe a stupid question but
> given that there is no need for a version of a module in the JDK,
> why do you want the JDK to reify the version value as a specific object with weird rules,
> why not considering that it can be any string (like in the JVM classfile format) ?
>
> regards,
> Rémi
>
> ----- Mail original -----
>> De: "David M. Lloyd" <david.lloyd at redhat.com>
>> À: jpms-spec-experts at openjdk.java.net
>> Envoyé: Lundi 21 Mars 2016 20:44:35
>> Objet: Re: Missing issue: Version string format
>>
>> On 03/21/2016 10:43 AM, David M. Lloyd wrote:
>>> On 03/21/2016 08:49 AM, David M. Lloyd wrote:
>>>> On 03/11/2016 04:13 PM, David M. Lloyd wrote:
>>>>> The current java.lang.module.ModuleDescriptor.Version class contains the
>>>>> comment:
>>>>>
>>>>> "Vaguely Debian-like version strings, for now.
>>>>> "This will, eventually, change."
>>>>>
>>>>> At some point the syntax and semantics of version designators has to be
>>>>> worked out and agreed upon.  Ideally the scheme would be compatible with
>>>>> as many existing widely deployed schemes as possible in terms of allowed
>>>>> syntax, and as much as possible, collation order (at least within the
>>>>> context of other modules from the same versioning scheme).
>>>>
>>>> Judging from the lack of response, I assume that nobody has done any
>>>> work on this, so I have a proposal.
>>>
>>> I just updated to the latest code and it looks like last week the scheme
>>> was updated.
>>>
>>> I would reframe this discussion into a proposal a few changes from the
>>> existing code.
>>>
>>> • Addition of a few more separator characters: the new code supports
>>> "+", "-", and ".", and also the transition types.  It does not support
>>> "_" which I believe to be in fairly wide use.  I would propose that this
>>> character be added as a valid separator.
>>> • The current code uses multiple "classes" of separators, which also
>>> depend on their location within the version string.  I suggest that if
>>> possible, a version sequence be agnostic to scheme, or else make
>>> versions layer-specific (similar to the #ModuleNameCharacters issue); I
>>> think the scheme I outlined would support all of the currently supported
>>> schemes with little or no adjustment.
>>> • The implementation is probably considerably heavier than it needs to
>>> be in terms of objects.  A zero-object representation is possible, as is
>>> a one- or zero-object tokenizer/validator.
>>>
>>> Unless someone has an early strong disagreement, I will prepare a
>>> prototype to illustrate the changes.
>>
>> I want to expand on this just a little more.  I think it is worth
>> dividing the concept of a version scheme from the concept of syntax of a
>> version string.  The former should be specific to a layer, and the
>> latter should be (if possible) global.  This allows layers to enforce
>> policy that makes sense to that layer, while also allowing predictable
>> (if not intuitive) interoperability between version schemes.
>>
>> My change will create a general parsing scheme for versions as
>> previously described, and move the specific validation rules to the
>> existent layers to which they are relevant, as necessary to pass tests.
>> --
>> - DML
>>

-- 
- DML