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

Tue Jun 25 21:48:15 UTC 2019

Hi,

I got back to this item and digged a bit deeper.

My current view on it:
I'm with Gil on not touching the current default milestone value (=unset) which yields a version output suffixed with "-internal".
As for the JDK_UPDATE_VERSION, I don't have objections on setting it and bumping it every quarter.
Regarding the JDK_BUILD_NUMBER, I'm still not sure about the right thing to do.

Why?
Let's first ask: What issues are we trying to solve?
a) Better indicate the type of the JDK build and the source level used.
b) Protect against wrongly creating GA builds which shouldn't be classified as such because the source level is not GA.

As for a): Currently, a plain, default developer build perfectly identifies itself by the "-internal" suffix. The "-ea" suffix is commonly used to indicate "official" pre-GA builds, which downstream builders usually would create consciously. This should not be the default. However, what's currently missing in the default output and would be really nice to have was the update version and the latest build number for the code base. So, if we would maintain the update version in the source and bump it every quarter, that would not be wrong. As for the build number, I still have bad feelings about maintaining it in the source code. We'd have a patch every week to indicate a new build, something that is semantically accomplished by repository tags already. So, if the build runs on a repository, I'd rather imagine that the build number can be parsed out of the repository tags. Ok, if somebody builds from a source drop, then it gets a bit more difficult. But maybe then the provider of the source drop should add the build number before spinning the archive?

As for b): What's the way for a builder of an "official" binary to classify a GA build of an OpenJDK 8 update release? It is setting "MILESTONE" to "fcs". This will trigger the assembly of a release type version output. You can't then tell from looking at the binary's version output whether the source was really GA level, unless you compare update level and build number with the repository's GA tag. All presupposed, the right update version and build number values were given to the build. So, changing/maintaining default values for update version and build number won't stop anybody who is building a release from a premature source drop. I have an idea, though, on how to fix this. We could implement kind of a fuse which will hit in that case. We'd need to add a GA-MILESTONE indicator, e.g. in version-numbers, that will be set to no/false in the beginning of an update release cycle. Once the GA state is reached, this flag should be set to yes/true. In the build system we need to add logic that would bail out if somebody attempts to do an fcs build while GA-MILESTONE is no/false. It should only work when it's set to true. If we were to build from a mercurial repository, we could evaluate the tags and see if the "ga" tag for the current update level is present. For a source drop, however, a hard coded value in version-numbers would probably be the way to go.

What do you think?

Best regards
Christoph

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of Gil
> Tene
> Sent: Mittwoch, 12. Juni 2019 05:33
> To: Andrew John Hughes <gnu.andrew at redhat.com>
> Cc: jdk8u-dev at openjdk.java.net
> Subject: Re: RFR: [8u] JDK-8225121 Set JDK_UPDATE_VERSION,
> JDK_BUILD_NUMBER and MILESTONE to correct values by default
> 
> 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