[11u] OpenJDK 11.0.3 post GA fixes JDK-8210739 and JDK-8203679

[Andrew Haley]

On 4/17/19 3:52 PM, Gil Tene wrote:

> IMO a release is a release, and should be properly identified and
> tagged as such. The OpenJDK 11u project releases source code, not
> binaries.  *If* an OpenJDK 11u project *release* is created after
> the OpenJDK 11.0.3 release and before the OpenJDK 11.0.4 release, it
> should be identified with an actual version (something better than a
> build number) which would show on the first line of the java
> -version output, and that version number should be displayed by any
> binary that purports to include the contents expected in that
> version.

Certainly. To begin with, I'd like to establish the principle, then we
can talk about exactly how we get it done. Everyone makes mistakes
from time to time, so it's quite possible that in the future we will
need to make a point release from a release branch. So, we must not
close off the ability to release (e.g.) 11.0.3.1 if we need to do so.

> Changes that go into such a release should be tagged with its
> version.  They clearly should NOT be tagged with 11.0.3, since an
> 11.0.3 *release* exists that does not contain them, and binary
> builds of that 11.0.3 release are already out.

Yes, that is certainly true.

> Tagging a change with a build number is an obvious oxymoron IMO. The
> “basic line numbers spacing” approach of tagging with a “far enough
> ahead to predict” build number gap that can be skipped to (e.g. b31
> for an anticipated BPR) may technically work when binaries are only
> available from a single source (e.g. Oracle), but it is very hard to
> maintain coordination of that gap. Using the build number in that
> way also creates the problem of having multiple “GA” builds of the
> same OpenJDK 11u version floating around, with no good way to
> distinguish released (“GA’ed”) builds from non released
> builds. E.g. what tells an end user that +7 and +31 are release
> builds, but +6 and +11 are not?

Agreed.

> JEP 322 has room for this sort of release-between-Releases thing
> with the $PATCH element in the version number. The $PATCH element is
> described in the JEP as “The emergency patch-release counter,
> incremented only when it's necessary to produce an emergency release
> to fix a critical issue.”. I would argue that anything that makes us
> create an unplanned release of OpenJDK 11u in the 3 months between
> the planned 11.0.3 date and the planned 11.0.4 date should qualify
> under that description (as if it does not, it should wait and go
> into the planned release).

That makes very good sense. However, that language rather implies a
single source of binaries (if not a single mind) and I don't want to
be in the business of arguing whether a particular issue is critical
enough. As long as we agree what a particular tag means, even though
not all of us might want to make a particular "emergency" release, I
think we're good.

We have a simple choice between declaring a release branch forever
closed, thus forcing people to maintain their own downstream forks
(or, worse, patch sets) if they need to make changes or finding a
co-ordinated way to do it.

> IMO the date shown in the first line of the JEP 322 version string
> should also be updated if such a hypothetical release is made.

Yes.

> The same cautionary logic applies to 8u, but there we don’t
> have a JEP 322 version number structure to use. IMO the proper
> thing to do for such unplanned releases in 8u (which I hope don’t
> need to use) would be to use the update number gap between
> e.g. the April 2019 8u212 and the July 2019 8u222 for an interim
> update release number (e.g. 8u216).

Again, yes.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671