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

Thu Apr 18 07:46:10 UTC 2019

Hi,

after catching up with this thread, I think Goetz' mail is a good abstract of the outcome.

I would withdraw jdk11u-critical requests from JDK-8210739 and JDK-8203679 then. Unless somebody objects... ��

Best regards
Christoph

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Lindenmaier, Goetz
> Sent: Mittwoch, 17. April 2019 22:55
> To: Gil Tene <gil at azul.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: [CAUTION] Re: [11u] OpenJDK 11.0.3 post GA fixes JDK-8210739 and
> JDK-8203679
> 
> Hi,
> 
> I agree with Severin that these changes are not severe enough to justify a
> release of their own.
> 
> I agree with Gil that we should bump a version digit and the date if we do so.
> 
> My few cents :)
> 
> Best regards, Götz
> 
> @Andrew Hughes: great the changes were pushed this timely! Thanks!
> 
> > Am 17.04.2019 um 19:34 schrieb Gil Tene <gil at azul.com>:
> >
> >
> >
> >> 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
> >