Proposal: Newer version-string scheme for the Java SE Platform and the JDK
neugens.limasoftware at gmail.com
Fri Nov 3 16:19:05 UTC 2017
On Fri 3. Nov 2017 at 17:06, Ben Evans <benjamin.john.evans at gmail.com>
> 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!
> 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  but even closer to the current scheme as defined in
> > JEP 223 . 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
> > 
> > 
> >  http://openjdk.java.net/jeps/223
More information about the jdk-dev