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

Fri Nov 3 16:19:05 UTC 2017

On Fri 3. Nov 2017 at 17:06, Ben Evans <benjamin.john.evans at gmail.com>
wrote:

> Broadly, this scheme seems to be an acceptable compromise.
>
> Thank you for taking the time to discuss, and for listening to concerns.
>
> A special thank you for not dooming the community to years of trying
> to explain "which version of Java we're developing with" to baffled
> recruiters when hiring.

They’ll still be baffled though!

Cheers,
Mario

> Thanks,
>
> Ben
>
> On Thu, Nov 2, 2017 at 8:11 AM,  <mark.reinhold at oracle.com> wrote:
> > 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 adopt.
> >
> >                                   * * *
> >
> > 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 follows:
> >
> >     $FEATURE.$INTERIM.$UPDATE.$EMERG
> >
> > where:
> >
> >   - $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:
> >
> >     $VNUM(-$PRE)?\+$BUILD(-$OPT)?
> >     $VNUM-$PRE(-$OPT)?
> >     $VNUM(+-$OPT)?
> >
> > 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:
> >
> >   java.version.date -- 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 release.
> >
> > Launcher
> > --------
> >
> > 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 own.
> >
> > I'll summarize relevant replies in about a week, and then draft a JEP.
> >
> > - Mark
> >
> >
> > [1]
> http://mail.openjdk.java.net/pipermail/jdk-dev/2017-October/000007.html
> > [2]
> http://mail.openjdk.java.net/pipermail/jdk-dev/2017-November/000088.html
> > [3] http://openjdk.java.net/jeps/223
>