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

[Matthias Klose]

On 17.04.19 19:33, Gil Tene wrote:
> 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.

well, I consider this fifth element a bit of nonsense, at least for distro based
rpm/deb packages.  Usually a package in the distro gets its version from the
upstream release, and the packaging revision from the packaging changes.  Adding
the packaging revision doesn't make a new upstream source.  Or you could have
separate source versions (including the "build" number, e.g. 11.0.3+b7-2), and
binary version (11.0.3.0.2), but then users are a bit confused to track back
source versions from binary versions. And even then you would mix native and
upstream Debian version numbers which is discouraged by Debian policy.

Matthias