Updating the version number
brian.goetz at oracle.com
Tue Dec 5 14:09:05 UTC 2017
The simple answer is: JSR 383 was known as "Java SE 18.3" from its
inception, so we retain it parenthetically to reduce confusion and
maintain continuity. I realize you view the calendar-based version
scheme as a mistake that ought to be erased from history with all
possible prejudice, but it makes sense to err on the side of continuity
with existing published information. So, I encourage you to look at
this change as "glass 99% full" rather than "glass 1% empty."
My interpretation of your comment is that it is not an objection, simply
a regret that we couldn't go farther. If my interpretation is
incorrect, please correct me. I want to get this to the PMO as soon as
On 12/4/2017 4:46 AM, Volker Simonis wrote:
> Why do we need to keep "(18.3)" in the name? In my personal opinion
> that version schema was a mistake and there's no need to keep any
> reference to it. "Java SE 10 (18.3)" looks rather confusing to me as
> opposed to simply saying "Java SE 10".
> On Fri, Dec 1, 2017 at 7:41 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>> I am sure everyone has seen the extensive discussions on version numbers.
>> Mark has recently posted a JEP capturing a concrete proposal:
>> The high-order bit here is that we're proposing going back to numbering
>> things 10, 11, 12, including the platform specification.
>> JSR-383 (https://jcp.org/en/jsr/detail?id=383) contains 11 occurrences of
>> the string "18.3":
>> - Title
>> - Description
>> - 2.1 Proposed Specification (2x)
>> - 2.3
>> - 2.14 links
>> - 2.15 RI and TCK (2x)
>> - 2.19 link
>> - 2.20 link
>> - 3 Contributions
>> Assuming no one here objects, I will ask the PMO to change all of the
>> non-link usages of "18.3" in the JSR to "10 (18.3)", as in "Java SE 10
>> (18.3)" or "The Java SE 10 (18.3) Platform Specification".
>> I will propose a similar change for JSR-384 (Java SE 18.9) once that JSR is
>> approved and the EG formed.
More information about the java-se-spec-observers