Version-string schemes for Java SE Platform & JDK: Oracle offers 3 alternatives
© Shutterstock / Yeexin Richelle
Last month, Oracle proposed a new version numbering scheme in order to emphasize the time-based releases. Not many people liked this proposal —to put it mildly— so Mark Reinhold is now offering three alternatives. You are encouraged to communicate additional information that’s relevant to the choice of such a scheme so speak now — a specific proposal will be made in about a week.
Not long ago, Mark Reinhold, the Chief Architect of the Java Platform Group at Oracle, proposed that the Java SE Platform and the JDK go from “the historical feature-driven release model to a strict, time-based model with a new feature release every six months, update releases every quarter, and a long-term support release every three years.”
To make it clear that these are time-based releases, and to make it easy to figure out the release date of any particular release, the version strings of feature releases will be of the form
$YEAR.$MONTH. Thus next year’s March release will be 18.3, and the September long-term support release will be 18.9.
Nicolas Parlog wrote in a recent blog post that even though two feature releases per year sounds good, “one problem with
year.month is that it looks like semantic versioning but isn’t — 18.9 might have more severe changes than 19.3, yet the latter incremented the ‘major version’, while the former did not.”
Although the six-month cadence proposal has received positive feedback, the new version numbering scheme is a different story. According to Gili Tzabari, “every product that has used time-based version numbers has inevitably dropped the approach (the only exception that comes to mind is MS Word).”
Also, every newcomer has to be taught about this, so they don’t go looking for 18.4. And heavens forbid one release is not on time, so there’s a 18.4 after all. Or the release months change because nobody works over the summer, so x.9 never had any interesting new features. (At least that would reestablish semantic versioning.)
Nicolai Parlog, Radical new plans for Java
Furthermore, Stephen Colebourne has written 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.”
Read the entire plea here.
Three concrete alternatives with pros & cons
Mark Reinhold acknowledged people’s feelings with regard to the strict, time-based model. For example, when announcing the proposed schedule for JDK 18.3, he did say “or whatever we wind up calling it” when referring to JDK 18.3.
Comments from JDK Committers are welcome, as are reasoned objections. If no such objections are raised by 18:00 UTC next Wednesday, 18 October, or if they’re raised and then satisfactorily answered, then per the JEP 2.0 process proposal this will be adopted as the schedule for JDK 18.3 (or whatever we wind up calling it).
Now, he’s come up with three alternatives for the new version-numbering scheme and he is inviting people to join the conversation (as long as they have something constructive to say). He’ll summarize “any new information received, and then make a specific proposal.”
(A) Absolute: $YY$MM, padding the month number with a zero as needed, and $YY$MM.$AGE for update releases, where $AGE is the number of months since $YY$MM.
(B) Absolute: $YY.$M as proposed, without padding the month number, and $YY.$M.$AGE for update releases, where $AGE is as above.
(C) Relative: $N, where $N is the number of half-years since JDK 9 GA (September 2017) plus nine, and $N.$AGE for update releases, where $AGE is as above. ($AGE is more useful than another incrementing counter since it leaves room for emergency update releases without having to renumber subsequent update releases that are already in development.)
This is how the next two feature releases and their first two update releases would look like:
Pros (+) and cons (-) of each alternative
(A) $YY$MM, with $YY$MM.$AGE for updates
(+) Has the three advantages of absolute times.
(+) The `Runtime.Version` API introduced by JEP 223 can be adapted fairly easily. Code that parses raw version strings would need little or no change (as long as it already does so correctly!).
(-) On the surface 1803 is an enormous leap from 9, is likely to cause confusion, and has connotations of being very old.
(B) $YY.$M, with $YY.$M.$AGE for updates
(+) Has the three advantages of absolute times.
(+) Similar to some other significant platforms, e.g., Ubuntu Linux, and less shocking in appearance than (A).
(-) People unfamiliar with the scheme could conflate 18.3 and 18.9 as being minor releases of JDK 18, which isn’t the case. There is some evidence of similar confusion around Ubuntu releases.
(-) The logical “major” version number is now a pair of numbers, year and month. We could mitigate this in the `Runtime.Version` API by encoding the year and month as $YY$MM in the existing major number, and adding new methods that return the year and month. Code that parses raw version strings will likely require change, including code not just in the JDK itself but in existing tools and CI systems.
(C) $N, with $N.$AGE for updates
(+) The most straightforward and least-surprising option, and familiar from other rapidly-evolving projects such as Firefox and Chrome.
(+) The `Runtime.Version` API can be adapted very easily, and code that (correctly) parses raw version strings would need no change.
(-) Lacks the three advantages of absolute times.
(-) If we ever switch to an even faster cadence then we could eventually have very large version numbers, as in (A). In the limit, we could wind up in a situation like that of CoreOS, whose latest stable release is numbered 1520.6.
According to Reinhold, many of the alternatives out there are “minor variants of these three.” He explained that representing the year with four digits instead of two would “lead to even longer version numbers and zero-padding the month number in (B) so as to be exactly like Ubuntu ($YY.$MM) —with the intention of making it obvious that JDK 18.03 is not an update release of JDK 18— “would only work so long as we never ship a feature release after September in any particular year.”
This is how you should give your feedback
You are requested to only communicate additional information that’s relevant to the choice of such a scheme. In short, your feedback should answer the following questions:
– Are there additional pros and cons to the alternatives listed above?
– Are there additional alternatives worth considering, and if so what are their pros and cons?
– Are there specific experiences with other projects or products that can inform this choice?
In about a week, he will summarize any new information received, and then make a specific proposal. So speak now — time is of the essence.