Numbering of updates in future 8u quarterly releases

[Andrew Hughes]

On Sat, 9 Feb 2019 at 03:58, Gil Tene <gil at azul.com> wrote:
>
> In the thread on "RFD: Draft guidelines for working on jdk8u", Andrew
> discusses doing one release per quarter in 8u going forward. I'd like
> to discuss the numbering of those expected update  releases, so that
> downstream builds will have an opportunity to align on a common
> meaning, and the consumers of various downstream builds would be
> able to tell what they are looking at…
>
> The relevant paragraph in the RFD e-mail is:
>
> > On Feb 7, 2019, at 10:01 AM, Andrew Haley <aph at redhat.com> wrote:
> > ...
> > Once a quarter, we will snapshot the jdk8u development tree and
> > prepare a Critical Patch Update (CPU) release. Once the snapshot has
> > been taken the engineers working on the CPU will work in the dark,
> > sharing the patches with only the OpenJDK Vulnerability Group. Any
> > patches not committed to jdk8u at the time of the snapshot will
> > probably have to wait for a later release. I don't propose to make any
> > non-CPU releases: one release a quarter should be quite enough for
> > jdk8u. However, if an urgent problem arises we might need to do make
> > an intermediate release.
> > ...
>
> AFAICT the closest things to the description above in past 8u update
> release are "PSU" releases with update numbers 8uXX2. For example
> 8u172, 8u182, 8u192, 8u202, … Those updates included both the
> latest security related patches (all the stuff included in the "CPU"
> 8uXX1 update releases such as 8u171, 8u181, 8u191, ...) as well as
> additional changes (bug fixes, minor features, etc.) accumulated since
> the previous 8uXX2 "PSU" release.
>
> Going forward (for everything after the current 8u202), what will these
> once-per-quarter updates be called?
>
> I see three main options:
>
> 1. Keep going with the existing convention, and use the 8uXX2 for the
> quarterly releases described in Andrew RFD e-mail. Continuing from
> where the January CPU/PSU versions (8u201 and 8u202) left off. So
> this coming April would be 8u212.
>
> 2. Do some sort of "skip" to denote the change from two (8uXX1 and
> 8uXX2) to one (8uXX2) quarterly release cadence. E.g. 8u302 for
> this coming April.
>
> 3. Go with some other, different-than-past cadence, and different
> meaning for the Y in 8uXXY going forward. (I'll use 8u777 as
> a placeholder example for this).
>
> My vote would be #1 above, for simplicity and continuity. I.e. 8u212
> for April, 8u222 for July, 8u232 for October, etc. etc. etc.
>
> — Gil.
>
>
>

This is an interesting point and one which also came up for OpenJDK 7
(the proprietary JDK 6 from Oracle was unrelated to OpenJDK 6, so the
problem didn't exist there). With 7, we have followed the CPU release numbering
of the proprietary Oracle JDK releases, so 7u201, etc.

With 8, that would effectively be a 4th option, as your #1 proposes following
the PSU numbering rather than the CPU. The obvious problem I see with
both is that there is a possibility of a proprietary Oracle variant existing
with the same version, and confusingly, having entries in the OpenJDK
bug system. 8u211 is already present in the OpenJDK bug system, I see.

It's not clear to me whether Oracle intend to continue doing both. As it seems
more likely that the PSU version is unused by Oracle, rather than the CPU
version, I'd say we go with #1 to reduce the risk of overlap.

Given how much more active 8 & 11 may be than 6 & 7 ever were, we may
have to consider further divergence at a later date. I think that's inevitable
and something to be embraced. We should encourage people to use the
OpenJDK versions of 8 & 11 where possible.
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com
Twitter: https://twitter.com/gnu_andrew_java
PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222