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

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Wed Apr 17 20:55:05 UTC 2019


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
> 


More information about the jdk-updates-dev mailing list