Proposal: Newer version-string scheme for the Java SE Platform and the JDK

Dave Franken dwfranken at
Thu Nov 2 15:35:45 UTC 2017

  > (1) Bearing in mind that no version-string scheme is ideal,
  >    is this scheme acceptable?

For me, this scheme is acceptable, it seems to be the least confusing one.

I think we, developers and users alike, all have to accept that, in order to
have nice things faster, we have to make sure we keep up with the latest
version and have to do so at a faster pace than we've done in the past.
Every released version is a stable version with added features, bug fixes,
etc; no betas or milestones.

Am I right in assuming that the main difference between LTS and non-LTS is
that fixes that fall in the interim, update or emergency category are
backported to LTS versions, but not to non-LTS versions?
So currently, 11 will be a LTS version, so if there is going to be a update
of non-LTS version 12.0 to 12.1, there will also be an 11.1, but not a 10.1?

Kind regards,

Dave Franken

-----Original Message-----
From: jdk-dev [mailto:jdk-dev-bounces at] On Behalf Of
mark.reinhold at
Sent: donderdag 2 november 2017 16:12
To: jdk-dev at
Subject: Proposal: Newer version-string scheme for the Java SE Platform and
the JDK

Here's a specific proposal, with commentary, and two questions.

Summary: This is a time-based scheme, similar to alternative (C) in my
earlier note [1][2] but even closer to the current scheme as defined in JEP
223 [3].  It's hence even less likely to surprise, and should be easier to

                                  * * *

Version numbers

A version number, $VNUM, is a sequence of numerals of arbitrary length,
separated by period characters.  The first four numerals are interpreted as



  - $FEATURE -- The feature-release counter, incremented every six months
    regardless of release content.  Thus the March 2018 release is 10,
    the September 2018 release is 11, and so forth.  Features may be
    added in a feature release; they may also be removed, if advance
    notice was given at least one feature release ahead of time.
    Incompatible changes may be made when justified.  (Formerly $MAJOR.)

  - $INTERIM -- The interim-release counter, incremented for non-feature
    releases that contain compatible bug fixes and enhancements but no
    incompatible changes, no feature removals, and no changes to standard
    APIs.  This counter is always zero for the current six-month release
    model.  We reserve it here to leave flexibility for the future, so
    that some future release model could say that JDK $N.1 and JDK $N.2
    are compatible upgrades of JDK $N.  Leaving this counter at zero for
    the current model has an additional benefit in that it increases the
    degree to which version numbers continue to reflect, roughly, both
    compatibility and significance.  (Formerly $MINOR.)

  - $UPDATE -- The update-release counter, incremented every three months
    for compatible update releases that fix security issues, regressions,
    and bugs in newer features.  Thus the April 2018 release is 10.0.1,
    the July release is 10.0.2, and so forth.  (Formerly $SECURITY, but
    with a non-trivial incrementation rule.)

  - $EMERG -- The emergency-release counter, incremented only when it's
    necessary to produce an emergency release to fix an urgent security
    issue.  Using an additional numeral for this purpose minimizes the
    disruption to both developers and users of in-flight update releases.

The fifth and later elements of version numbers are reserved for use by
downstream consumers of the JDK code base.  The fifth element may be used
to, e.g., identify implementor-specific patch releases.

This is primarily a time-based scheme, since $FEATURE is incremented every
six months regardless of release content and, for each feature release,
$UPDATE is incremented every three months.  We do expect most feature
releases to contain at least one or two significant features, and never to
ship interim releases under the new release model, so in practice this
scheme will often be very similar to a compatibility- or
significance-oriented scheme like that of JEP 223.  JDK 10 is a feature
release, JDK 10.0.1 and 10.0.2 are update releases with compatible bug
fixes, and there is no interim JDK 10.1 release since in this model the next
opportunity to add features is JDK 11.

Version strings

The overall format of version strings is unchanged.  A version string is a
version number, $VNUM, optionally followed by pre-release, build, and other
optional information, one of:


where $PRE is a pre-release identifier (e.g., `ea`), $BUILD is a build
number, and $OPT is optional build information.

Implementors who offer long-term support for a release should use an $OPT
string that starts with "lts", e.g., 11.0.2+13-lts.

System properties

To the system properties mentioned in JEP 223 we add one new property: -- The GA date of this version, in ISO-8601
  YYYY-MM-DD format.  For EA releases this will be the intended GA
  date, i.e., some date in the future.  This value is not part of the
  version string per se, but it will be displayed when useful and can
  be retrieved via a new method on the `Runtime.Version` API.

This new property makes it easy to figure out how old a release is, so that
as a user you can understand how far behind you are.  It also reflects the
security level of the release: A given GA release contains the latest
security fixes if its version date is no earlier than that of any other GA


The `java` launcher will display version strings and system properties as
follows, for a hypothetical build 13 of JDK 10.0.1:

    $ java --version
    openjdk 10.0.1 2018-04-19
    OpenJDK Runtime Environment (build 10.0.1+13)
    OpenJDK 64-Bit Server VM (build 10.0.1+13, mixed mode)

Similarly, for a hypothetical build 42 of JDK 11, an LTS release:

    $ java --version
    openjdk 11 2018-09-20 LTS
    OpenJDK Runtime Environment (build 11+42-lts)
    OpenJDK 64-Bit Server VM (build 11+42-lts, mixed mode)

                                  * * *

If you've read this far, two questions:

  (1) Bearing in mind that no version-string scheme is ideal,
      is this scheme acceptable?

  (2) If this scheme is not acceptable then please explain why,
      and identify exactly what you would change.

Ground rules, as before: I'll give much greater weight to your first reply
to this message than to any other, I'll ignore replies-to-replies, and I'll
heavily discount replies that quote more text than add new text of their

I'll summarize relevant replies in about a week, and then draft a JEP.

- Mark


More information about the jdk-dev mailing list