RFR: [8u] JDK-8225121 Set JDK_UPDATE_VERSION, JDK_BUILD_NUMBER and MILESTONE to correct values by default

[Andrew John Hughes]

On 10/06/2019 11:12, Matthias Klose wrote:
> On 31.05.19 18:28, Andrew John Hughes wrote:
>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8225121/webrev.01/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8225121
>>
>> The intention of this simple patch is to provide better defaults for the
>> version output for 8u, which should hopefully make issues with unclear
>> 'ea' builds less frequent.
>>
>> The default version output post patch is:
>>
>> $ /mnt/builder/8u-dev/images/j2sdk-image/bin/java -version
>> openjdk version "1.8.0_222-ea"
>> OpenJDK Runtime Environment (build 1.8.0_222-ea-b06)
>> OpenJDK 64-Bit Server VM (build 25.222-b06, mixed mode)
>>
>> My intention is to reuse this bug ID once approved to update these
>> values as part of the regular tagging process. 8u allows changesets to
>> use the same bug ID and I think that's better than having new bugs every
>> week! It also automatically collates all such changes in the bug database.
>>
>> Going forward, the process will be:
>>
>> * Weekly tag: Update JDK_BUILD_NUMBER to new value
>> * Branch for next release: JDK_UPDATE_VERSION updated and
>> JDK_BUILD_NUMBER reset to b01 in 8u-dev only
>> * Release: Update MILESTONE to "fcs" to produce release builds.
>>
>> Does this sound ok?
> 
> that sounds fine.
> 
> On top of that, should the vendor by changed from `Oracle' to `OpenJDK'?  At
> least would differentiate the OpenJDK build from the Oracle build.
> 
> Matthias
> 

Technically, the vendor is currently set to 'N/A' which is then special
cased in the build to mean 'unset', so that the underlying Oracle value
in the source code comes through instead.

My reluctance to change this is that I believe some applications
(wrongly) check this value. We've had bugs raised for it a couple of
times, and this is why we've avoided changing it in our builds. OpenJDK
11 is a slightly different case, because it's relatively new and already
breaks a whole heap of compatibility stuff anyway. 8u is stable and
people stick with it to avoid those kind of breakages.

So I'd need a strong case to suggest changing that at this juncture.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (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