Coordinating the build number for 11.0.3

[Gil Tene]

Sent from my iPad

On Apr 1, 2019, at 2:25 AM, Matthias Klose <doko at ubuntu.com <mailto:doko at ubuntu.com>> wrote:

> On 30.03.19 20:54, Langer, Christoph wrote:
>> Hi Gil, Andrew,
>> 
>> I don't really like the idea to define the exact build number beforehand with leap space for additional builds.
>> 
>> However, I can see that it would be helpful for distributions that want to release a binary right at the release day without waiting for the public release of the CPU changes, then picking them up, merging, triggering builds and do regression testing. Doing so will obviously delay the availability of the binaries and incurs some uncalculatable risk regarding merging and regressions.
> 
> How important is this? At least for Linux distributions you always have
> something like <upstream version>-<distro release version>, so you can do
> multiple builds, and even adding the CPU changes as a bumped distro release
> version without waiting for the CPU merges.

Using the ana;ogy above, the build number in e.g. 11.0.2+9 clearly belongs on the <upstream-version> equivalent part. There is a completely separate portion of the JEP 322 version string where the different binary builds have been placing the <distro release version>equivalent part, which has room for it's own subversions and build notions. See the below for how the latest 11.0.2 (+9) looks for some common builds (and it looked the same for the initial +7 version that came out as well).

Zulu 11:
Lumpy.local-37% Contents/Home/bin/java -version
openjdk version "11.0.2" 2019-01-15 LTS
OpenJDK Runtime Environment Zulu11.29+11-CA (build 11.0.2+9-LTS)
OpenJDK 64-Bit Server VM Zulu11.29+11-CA (build 11.0.2+9-LTS, mixed mode)

AdoptOpenJDK 11:
Lumpy.local-51% Contents/Home/bin/java -version
openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.2+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.2+9, mixed mode)

Cortretto 11:
Lumpy.local-63% Contents/Home/bin/java -version
openjdk version "11.0.2" 2019-01-15 LTS
OpenJDK Runtime Environment Corretto-11.0.2.9.1 (build 11.0.2+9-LTS)
OpenJDK 64-Bit Server VM Corretto-11.0.2.9.1 (build 11.0.2+9-LTS, mixed mode)

Oracle-built OpenJDK 11 builds:
Lumpy.local-41% Contents/Home/bin/java -version
openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)


> 
>> So, maybe we can agree that the final build number will always be the publicly visible build number + 1. Andrew, not knowing your exact processes regarding the handling of CPU changes, would you think you'd be able to commit to that?
>> 
>> Best regards
>> Christoph
>> 
>> 
>>> -----Original Message-----
>>> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net <mailto:jdk-updates-dev-bounces at openjdk.java.net>> On
>>> Behalf Of Andrew John Hughes
>>> Sent: Samstag, 30. März 2019 03:19
>>> To: jdk-updates-dev at openjdk.java.net <mailto:jdk-updates-dev at openjdk.java.net>
>>> Subject: Re: Coordinating the build number for 11.0.3
>>> 
>>> 
>>> 
>>> On 29/03/2019 22:02, Gil Tene wrote:
>>>> As we approach the April update and the release of 11.0.3 by the
>>>> JDK11u project, I'd like to suggest a coordination of the eventual
>>>> build number that we expect to use for the actual released build in
>>>> the project (after integration of security fixes that are being worked
>>>> on in the dark).
>>>> 
>>>> Since the build number is a part of the versions string per JEP 322,
>>>> and since this is the most specific part of the version string that is
>>>> common across the various binary distributions (e.g.
>>>> Azul Zulu, AdoptOpenJDK, Corretto, Liberica, Red Hat, etc.), it
>>>> is useful for us all to use the same build number when we release
>>>> the first build of a new update of 11u. This has been the practice in
>>>> the past. E.g. for 11.0.2, we all aligned on the same "build 11.0.2+9"
>>>> in the version string.
>>>> 
>>>> Since the update itself is time sensitive, and it is useful to commence
>>>> testing ahead of time, knowing the build number to use in the builds
>>>> we test would be helpful in getting the builds ready to go ASAP once
>>>> the release is finalized.
>>>> 
>>>> So, I propose that we pre-choose a build number for the anticipated
>>>> April release of 11.0.3. I have no strong opinions on what that number
>>>> should be. It should probably not overlap with past or current builds of
>>>> 11.0.3 in 11u, and "leaving room" (a gap of a few integer spaces
>>>> between the current build numbers and the anticipated one) is probably
>>>> a good idea.
>>>> 
>>>> — Gil.
>>>> 
>>> 
>>> Well, it's already at 5:
>>> 
>>> https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd4470fa81fe <https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/dd4470fa81fe>
>>> 
>>> So I would expect the CPU additions to make it 6, but it may have to go
>>> higher if issues arise.
>>> --
>>> Andrew :)
>>> 
>>> Senior Free Java Software Engineer
>>> Red Hat, Inc. (http://www.redhat.com <http://www.redhat.com/>)
>>> 
>>> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
>>> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
>>> https://keybase.io/gnu_andrew <https://keybase.io/gnu_andrew>
>>