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

[Gil Tene]

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.

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.

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?

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).

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.

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).

— Gil.

> On Apr 17, 2019, at 6:18 AM, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Hi Andrew,
> 
> so, the CPU is out. May I please ask you to decide on whether these two additional fixes shall be pushed to jdk11u and an additional jdk-11.0.3+8 tag shall be done. I think the case is similar as with jdk8u212-b04. One could of course also go in the sense of Severin's mail and defer people to the 11.0.4 EA builds. But I guess it's kind of a service to the community to add the two changes on top of 11.0.3 GA since they are part of the Oracle builds as well.
> 
> Thanks
> Christoph
> 
> 
>> -----Original Message-----
>> From: Andrew Haley <aph at redhat.com>
>> Sent: Dienstag, 16. April 2019 10:40
>> To: Langer, Christoph <christoph.langer at sap.com>; jdk-updates-
>> dev at openjdk.java.net; Andrew John Hughes <gnu.andrew at redhat.com>
>> Cc: Martijn Verburg <martijnverburg at gmail.com>
>> Subject: Re: [11u] OpenJDK 11.0.3 post GA fixes JDK-8210739 and JDK-
>> 8203679
>> 
>>> On 4/16/19 9:02 AM, Langer, Christoph wrote:
>>> 
>>> I suggest we push both of these fixes (which apply cleanly and are
>>> pretty local to their area) to jdk11u after Andrew (Hughes) has
>>> pushed the CPU changes and after that add a jdk-11.0.3+8 tag. Then,
>>> downstream vendors can chose to create another update based on the
>>> new tag if they need to deliver binary versions that include these
>>> fixes. I'll also run these fixes through our SAP test system but I
>>> don't expect any regressions.
>>> 
>>> Any opinions?
>> 
>> Once the CPU release is out, any suitably qualified person may request
>> pushes from 11u-dev to 11u, and anyone may make a release from 11u. I
>> know of no reason why people should not tag intermediate releases.
>> 
>> --
>> Andrew Haley
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671