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

[Gil Tene]

Wait, if I read this right, the proposed changes will:
A) make what used to default to “-internal” now default to “-ea” instead.
B) make what used to default to “-internal” now default to nothing (i.e. fcs) in certain
    (quarterly release) versions of the source.

If so, I don’t see how this is a good thing. I think it will only serve to exacerbate the
sort of problem you are trying to solve.

IMO "-internal" is much more appropriate and scary (in a good way) default tag than
"-ea" is for what people might randomly build against some random version of sources
'that they got, using the latest version of glibc on their latest and greatest desktop setup.

More importantly "-internal" is absolutely the appropriate tag for the thing that comes
out of me downloading the released sources and building them on my desktop today,
with my own hacked version of glibc and associated headers, using my private version
of gcc, with warnings and some annoying errors turned off for expediency. The result
of doing that (right now) shows 1.8.0-internal. That is as it should be.

I’m all for ways to make it more clear that the non-released stuff is EA (and should be
tagged as such if built to be shared with others), but I don't think we should break the
well established developer workflows and the existing safeguards against creating
unintentionally-tagged-as-something-consumable things in order to do so.

IMO "fcs" should *never* show up as a milestone value in the checked-in version of
any files. Using it in a build should be an intentional act, meant to to put that milestone
on a build, in that specific build environment, and not something we encourage
happening "by accident" on every developer desktop around the world that happens
to download the sources. The thing being built from those sources on some random
setup may be very far from the thing you'd want to tag as "fcs" (and may fail many tests)
and there are many new failure scenarios and bad build leakage issues we will create
if we make this the default tag for builds from quarterly released sources…

We've had a working flow for a decade+ now, and many different good builds that use
that flow. It tags builds as dangerous by default. It relies on internal builds (and their build
environment) being stabilized, tested, and sanity checked before any "for external
consumption" tag is placed on the output of the "now we really mean it" build that we
produce in the same environment, and repeat the tests on.

Let's not break that well established flow.

If we want to *add* an additional, harder to remove "EA" tag (so that it will show both
 -internal and the ea thing, and that even with an fcs milestone it will still show EA
unless it was removed (or was not there because the sources are form an actual
release), I'd be supportive. But taking off the belt and suspenders (removing the
default "-internal") and cutting a little into the break lines (making fcs default in
released source versions) because we think the drivers of these build scripts are
experienced enough to run with scissors is something that should be done only
after a lot of more sober introspection and sleeping on things.

— Gil.

> On Jun 11, 2019, at 7:32 PM, Andrew John Hughes <gnu.andrew at redhat.com> wrote:
> 
> 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