Version-string schemes for the Java SE Platform and the JDK

[Roman Kennke]

> Yes, i was thinking exactly the same things reading the comments on this thread,
> 2018.3 is the distribution version, a position on the time axis while 10.0.0 is the internal version, a position on the compatibility axis (following JEP 223).
Oh no! Why?

We've been there before. For a bunch of releases the new version scheme 
(e.g. 6) was used outside, for marketing purposes, and the internal 
version still used the old scheme (e.g. 1.6.0). Has it done anything 
good to anybody? It just makes things more complicated, especially when 
there is no easy mapping (there was one back then: you could go from 
Java $X to Java 1.$X.0 relatively easily).

I've read through most arguments and explanations, and one thing I 
really still cannot point my finger at is the big 'why?' What pressing 
need do we have to change version numbers *once again*, now that we're 
finally at a point where everybody has internalized the current scheme? 
For the most part, Java history nowadays starts at Java6. (Yes I know 
there's the lone old 1.4 deployment here and there.) A change like this 
is causing friction and disruption all over the place (and not in a 
positive sense), and this seems only justified when we have really good 
reasons to do so. I still cannot see them.

On the upside, does this mean that Java is so good that we don't have 
more important issues to argue about and spend our time and energy on? 
(I don't think so. I'd like to see similarily lively discussions about, 
the vulnerability group, how JPRT can be made accessible to the outside 
world, if/how to open source the TCK, just to name 3 examples that I 
consider relatively important).

Cheers, Roman