Draft JEP: Time-Based Release Versioning

[mark.reinhold at oracle.com]

2017/12/1 3:11:18 -0800, volker.simonis at gmail.com:
> thanks for publishing the draft. Overall it looks good!
> 
> I have just a few comment :)
> 
> 1. Is this JEP (i.e. the new version scheme) intended to be targeted
> for Java 10?

It's intended to be targeted when it's ready, just like any other JEP.
It's obviously desirable to have it in 10, but if it doesn't make it
then it'll be in 11.

> I would appreciate to have it in ten but aren't we already quite late?
> This is specification relevant (i.e. has to go into JSR 383) because
> it changes java.lang.Runtime.Version and various standard system
> properties which refer to it. JSR 383 has to be renamed from "Java SE
> 18.3 Platform JSR" to "Java SE 10 Platform JSR" afterwards, right?

That should be done anyway, regardless of whether this JEP makes it into
JDK 10.  If we change nothing in JDK 10, as it stands today, then the
JDK 10 GA release will identify itself as 10, not 18.3.

> 2. In the example output there a space between the date and LTS when
> running java --version:
> 
> $ java --version
> openjdk 11 2018-09-20 LTS
> 
> But in the formal definition of the "--version" output there is no space:
> 
> $ java --version
> openjdk ${java.version} ${java.version.date}${LTS}
> 
> I suppose the example output is correct here and there should be a
> space between ${java.version.date} and ${LTS} in the formal
> definition, right?

The JEP defines ${LTS} to expand to " LTS".  (I put a non-breaking space
after the opening double quote to try to make that clear, but to be even
clearer I could instead write "\u00020LTS".)

> 3. The same applies to the space between
> ${java.runtime.name}/${java.vm.name} and ${JVV}

Same answer.

> 4. Finally, why are the outputs of "-version" and "--version" slightly
> different? Is this to retain backwards compatibility with the former
> "-version" output? But then why can't "--version" use the exact same
> format? Sorry if this has been discussed before. It is obviously not a
> crucial factor but I just found it confusing when looking at it.

When we introduced `--version`, `--show-version`, and `--full-version`
in JDK 9 we took the opportunity to clean up and simplify the output.

- Mark