Another leap forward: Oracle announces proposed schedule for JDK 18.3
© Shutterstock / xtock
Mark Reinhold, the Chief Architect of the Java Platform Group at Oracle, has just announced a proposed schedule for JDK 18.3. The milestone definitions are the same as for JDK 8 — there will be no “Feature Complete” milestone though.
Mark Reinhold, the Chief Architect of the Java Platform Group at Oracle, announced in a message to the OpenJDK mailing list that the proposed schedule for JDK 18.3 is as follows:
2018/01/11 All Tests Run
2018/01/18 Rampdown Phase Two
2018/02/22 Final Release Candidate
2018/03/20 General Availability
— Mark Reinhold (@mreinhold) October 11, 2017
According to Reinhold, the milestone definitions are the same as for JDK 8.
There’s no “Feature Complete” milestone since, in the six-month model, every feature must be complete before it’s integrated. The main development line is, in effect, always feature complete. The set of features in the release contains all, and only, those features that are integrated ahead of Rampdown Phase One.
Reinhold added that he would soon propose a detailed definition of what it means for a feature to be “complete”. However, he did mention that the definition “will be along the lines of what the milestone has always meant for past releases: A complete feature includes, at the very least, all necessary code, specification text, and unit tests.”
If no objections are raised by October 18, 18:00 UTC “or if they’re raised and then satisfactorily answered,” the proposal will be adopted as the schedule for JDK 18.3 (“or whatever we wind up calling it”).
SAP’s Volker Simonis asked if this means that the JDK 18.3 repository “will be created (i.e. forked) just before “Rampdown Phase One” is entered” and wanted to know what’s the working model after the fork of JDK 18.3.
What will be the working model after the fork of jdk-18.3? Will bug fixes for 18.3 have to go to jdk-dev first and then backported to jdk-18.3 or can they be pushed right into jdk-18.3? In the latter case, will there be an automatic integration process of fixes from jdk-18.3 into jdk-dev?
“Or whatever we wind up calling it”: Is there still hope for the old numbering scheme?
Speaking of the old vs. new numbering scheme, this topic came up during the JAX London panel with Oracle’s Donald Smith, Daniel Bryant, Stephen Colebourne, Peter Lawrey and Martijn Verburg.
— JAXenter.com (@JAXenterCOM) October 11, 2017
(from left to right: Donald Smith, Peter Lawrey, Martijn Verburg, Stephen Colebourne, Daniel Bryant)
— JAX London (@jaxlondon) October 11, 2017
There was an interesting exchange of ideas with regard to the new numbering scheme — Stephen Colebourne said that he is dissatisfied with the proposal but that doesn’t come as a surprise: he recently wrote a plea “for sane Java version numbers such as 10, 11, 12”.
He believes that even though “the LTS release is important to Oracle and big business, it will be pretty unimportant to the community.” Furthermore, “a year/month scheme is unusual and unexpected.”
Stephen proposes that “versions should simply increase incrementally”:
March 2018 — v10
September 2018 — v11
March 2019 — v12
September 2019 — v13
and so on.
Read the entire plea here.