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

[Gil Tene]

> On Apr 17, 2019, at 9:33 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> 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.

I think that project is the place for us to coordinate and choose the
expected contents of releases with specific combinations of the
first 4 elements in e.g. 11.0.3.1 . The $PATCH element should be
"owned" by the project, and the decision to use it and rev it should
be up to the project maintainers (and ultimately the project lead), so
we do have that "single mind" that makes those choices.

JEP 322 leaves the 5'th element (e.g. 11.0.3.0.X) for downstream-specific
identification:

"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 gives us a separate place for subjective, binary-distro-specific
or vendor specific choices on issuing patches or differences that are not
in a project release, but are "based off of" some project release.

So e.g. if a specific distro or vendor wanted to make changes after
some hypothetical 10.0.3.1 project release, and before 10.0.4, but
still wanted to identify their release as "includes everything in 10.0.3.1
but says nothing about 10.0.4"), they would use something like
10.0.3.1.17.

I think that the JEP makes it clear that we should not expect the
numbers in that 5th element position to have meaning outside of
the world of a specific downstream distribution or implementor.

So IMO multiple implementors can be free to use the same
(and overlapping) numbers in the fifth element without sowing confusion.
But we should try to avoid repurposing or using any of the other
elements (the 11.0.3.0 part of 11.0.3.0.17) in non-coordinated ways.

Our preference (at Azul) has been to only use the 5th element when
we actually have a release that falls in between project releases from
a contents perspective. E.g. we have an 11.0.2.0.101 release, but
we use 11.0.2 and 11.0.3 for the things that are aligned with
OpenJDK 11u 11.0.2 and 11.0.3.

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