Missing issue: Version string format

[Remi Forax]

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
>