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

mark.reinhold at mark.reinhold at
Thu Oct 19 22:49:52 UTC 2017

2017/10/19 9:25:24 -0700, Ryan Schmitt <rschmitt at>:
> One common reason for discussions to devolve into bikeshedding is that they
> have become unmoored from any particular problem-solving activity, and
> discussion participants are much more anxious to express their subjective
> aesthetic judgements than to make careful engineering evaluations. You've
> laid
> out a very detailed explanation of the different considerations involved in
> designing a versioning scheme. However, Java already *has* a versioning
> scheme,
> as codified in JEP 223, and it is not self-evident why a six-month release
> train as opposed to a two-year release train would invalidate that scheme.
> So I
> would like to request clarification: what problem are you trying to solve?

It's so simple to state that I supposed it was obvious:

  Given the new release model, what is the best version scheme for
  the Java SE Platform and the JDK?

Shifting from an irregular multi-year cadence to a strict time-based
cadence is a big change, so it's worth asking the question.  Perhaps
the scheme defined in JEP 223, which can be seen as a variant of
alternative (C), is best -- but perhaps there's something better.

- Mark

More information about the jdk-dev mailing list