Version-string schemes for the Java SE Platform and the JDK (original) (raw)

Stephen Colebourne scolebourne at joda.org
Wed Oct 25 11:45:24 UTC 2017

On 19 October 2017 at 16:08, <mark.reinhold at oracle.com> wrote:

- Compatibility -- "Will my code break if I upgrade to this release?" - Significance -- "How different is this release from what I have now?" - Security -- "Does this release contain new security fixes?" - Support -- "For how long will this release be supported?" - Identity -- "On exactly which build was this bug reported against?" - Time -- "When did this release ship? How far behind am I?"

Lets rule out axes that are not important first. "Significance" is the same as compatibility in most cases. "Security" is orthogonal. "Identity" should be dealt with by any sensible version scheme. "Time" is of no importance to any library/platform I've ever dealt with - you simply look it up if you need to care.

Compatibility must be the key driver for versions. The broad rules of semver (semantic versioning) are widely adopted and understood within the software industry and any departure from it should be treated with great scepticism. Note that when I mention semver I consider it to be a general framework rather than a strict set of rules to follow - not everyone will make that distinction.

As such, there will be general agreement around a number following the pattern x.y where the first number is the major version and represents the fundamental compatibility level of the software.

The proposal 18.3 / 18.9 / 19.3 etc. is extremely objectionable because it gives the appearance of being a semver when it isn't. The issue is that a major change may occur in 18.9, which is 100% wrong in semver-style versioning. It gives the appearance of having made a major breaking change in a minor release - a massive no-no.

As such, all version schemes using two separate digits where a major change happens with only the second digit changing MUST BE REJECTED. If a release can contain a major change then the first version number must change (unless the beta approach is used, see below).

A "major change" must include at least language enhancements, method/class/module deletion and class file version change. As I understand the next few releases, each release will have at least one of these, and as such each one triggers a major release which requires the first "major" digit of the version number to change.

A "minor change" would include adding a new method to an existing API, adding a new class/type, adding a new module. All of these would be fine to be accepted in the second "minor" digit of the version number with the "major" digit staying the same.

...the set of features is not known until late in each release cycle, after the final feature is merged. ... then would the March 2018 release be version 9.1, or 10? We can't know until some time in December 2017, when the release closes for stabilization.

Personally I don't think this is a major problem. In most systems I've worked on you allocate the number as being minor until someone commits a major change and then bump it to major. ie. March 2018 would be named 9.1 until a major change is committed when it would then be changed to 10. However, given how rare a minor-only release is likely to be, I don't think this is worth pursuing.

- The support lifetime of a release is useful information, but it's not appropriate to encode that into the version number of the Java SE Platform or the JDK. The version number should be identical in all implementations of a given release, but the support lifetime of a release may vary from implementor to implementor.

The "Support" axis is the wildcard in the whole discussion. While it is true that in theory an implementor might provide LTS for release other than those that Oracle provides LTS for, there is a huge open question of whether they will, or whether it would be appropriate for them to do so. This is a huge missing piece of the puzzle on versioning, and can radically change the result of the discussion:

For example, if Oracle and the community were to agree that LTS releases are the new "real" releases, then the most appropriate version scheme would be one that reflected that:

9 (Set 2017) - now designated an LTS release 10-BETA-1 (Mar 2018) 10 (Sept 2018) - an LTS release (example) 11-BETA-1 (Mar 2019) 11-BETA-2 (Sep 2019) 11-BETA-3 (Mar 2020) 11 (Sep 2020) - an LTS release (example) etc

This is really clear as to what the releases are - beta releases in preparation for an LTS. It is also much clearer that you shouldn't use them once the next beta is out. Obviously some organizations reject using beta code in production, but they would probably be the same organizations that will only use an LTS anyway.

To adopt this requires broad agreement from all OpenJDK participants that LTS releases are the only full releases (and implied in that is probably that Java SE 9 is a "real" release simply because of its name).

These considerations leave us with the final axis, time, as the leading candidate for the primary basis of Java SE and JDK version numbers.

As indicated above, I (and many others) reject this conclusion, and thus most of the rest of the arguments in the email are null and void.

- Are there additional pros and cons to the alternatives listed above?

(B) fails the essential test that a major change MUST NOT occur in the second digit. As such it is immediately rejected.

(A) and (C) do meet the test, although the reason suggested to use the age in months as the second digit is both weak and unnecessary. A third digit can represent emergency releases, or the update releases could go in units of 20 as now.

(A) is weird because the number is so large. Developers talk about the Java version they use all the time, and this would make those discussions painful. And since the date of a release is in general completely unimportant, it should be rejected anyway.

The description of (C) is weird because of the nonsensical attempt to link the first number in the scheme to time. If it is just a number then the potential problem of 3 monthly releases goes away.

- Are there additional alternatives worth considering, and if so what are their pros and cons?

I've outlined the BETA scheme above. To me it most clearly represents what the wider community would expect, as I think if you asked them, only LTS releases with support would count as "real" releases worthy of changing the first digit, and all other "releases" are simply betas working towards the LTS. Note that this implies that no piece of functionality can be deprecated in BETA1 and removed in BETA2, which would be a sensible approach anyway.

The main con of the BETA scheme is that it encodes a specific LTS model into the version scheme. And I suspect there might be some pushback on the principle of downgrading 6 monthly release relative to the LTS ones. In my view this is actually just a statement of fact - as without support you are forced to upgrade making them clearly a lower grade of release.

Now, if RedHat or someone else were to publicly say that they will support every 6 monthly release for a 5 year period, then the BETA scheme doesn't work. But IMO, the community would be better served by a widely agreed LTS release every 2 to 3 years, with BETA releases in between for advanced users.

If the BETA scheme is rejected, the default should be to continue using the existing scheme - a simple incrementing number - 10, 11, 12, etc. This fits with JEP 223, causes no particular pain or issues with the wider community. The pros of this scheme are that it is well known, well understood and already works. It has the con that it doesn't help Oracle ship software on time, but thats not something that the version scheme should care about (and might even be viewed as a positive on rare occasions). See also David Lloyd's pros/cons of the current incrementing number scheme.

- Are there specific experiences with other projects or products that can inform this choice?

Java is a software platform, not an OS. It is closer to Apache Tomcat or Spring Framework than Ubuntu. So numbering schemes used by open source projects and maven central (almost all based on semver) should be the guide here.

Summary:

As others have emphasised, JEP 223 has discussed and decided this issue. There would have to be a very good reason to change the approach.

The only justification I can possibly see is that there are now two grades of release - intermediate (no support beyond 6 months, thus forced upgrade) and full (LTS). None of the proposals in the original email represent that key distinction - the BETA scheme above does of course.

Unless there is wide agreement on the concept of beta releases leading to a full LTS release, the only rational choice it to retain the existing JEP 223 numbering scheme, thus March 2018 is v10 and September is v11.

Stephen

More information about the jdk-dev mailing list