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

[Gil Tene]

> On Apr 17, 2019, at 6:21 PM, Matthias Klose <doko at ubuntu.com> wrote:
> 
> 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.

I have no strong opinions on whether or not the choices made in JEP322 are
"good" or bad", "smart" or "nonesense", or even on what the version scheme
for OpenJDK 15 might look like. I just have a strong opinion on not revisiting
the matter for OpenJDK 11.

> 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