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

Andrew Hughes gnu.andrew at
Thu Oct 19 18:29:56 UTC 2017

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


> Examples of these alternatives, for the next two feature releases and
> their first two update releases:
>                                (A)       (B)       (C)
>     GA (March 2018)            1803      18.3      10
>     First update (April)       1803.1    18.3.1    10.1
>     Second update (July)       1803.4    18.3.4    10.4
>     GA (September 2018)        1809      18.9      11
>     First update (October)     1809.1    18.9.1    11.1
>     Second update (January)    1809.4    18.9.4    11.4

I have a slight preference for one over the other - and would prefer
a clean break with the past - but these are similar for the most part.
My main concern is with how the Long-Term Support (LTS) releases
fit into this picture.

For this, we need to move further forward than the first short-term
release and the first LTS release in September 2018. I've used scheme B,
and assumed that the security macro number is increasing by three,
to allow space for unscheduled updates.

GA (March 2019): Release of 19.3.0
First update (April 2019): Release of 19.3.1 *and* 18.9.7.
Second update (July 2019): Release of 19.3.4 and 18.9.10

Now, with 19.3.0, the version is greater than 18.9.4, but they
are of the same security status.

Our first issue comes in April 2019, when 18.9.7 is now more
secure than 19.3.0, but 19.3.0 has the greater version number.

Similarly, in July 2019, 19.3.0 and 19.3.1 will be less secure than

This was true before, with e.g. 7u141 having security fixes that weren't
in 8u121, for example, but there was also a clearer separation between
a major version and updates for it. I guess my point is that there's nothing
immediately clear about a version like 18.9.x that says it should be treated
differently to 18.3.x, 19.3.x, 19.9.x and so on. Indeed, there are going to
be updates to major version 18 that are more up-to-date with security fixes
than any release of major version 19 or 20, the next LTS release being 21.9.
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (

Web Site:
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

More information about the jdk-dev mailing list