Missing issue: Version string format

[David M. Lloyd]

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