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

Andrew Hughes gnu.andrew at redhat.com
Wed Sep 16 17:47:16 UTC 2020


On 21:48 Tue 25 Jun     , Langer, Christoph wrote:

snip...

> 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?
> 

I don't really see how that's any different to setting MILESTONE=fcs
when the GA milestone is reached, and back to ea afterwards. Why would
a new flag be needed?

We're currently setting MILESTONE=ea/fcs (depending on state) in
downstream builds. For RHEL & Fedora, these changes need to be made in
just shy of a dozen places, due to all the various active releases
that carry OpenJDK 8. To my mind, that process is far more error-prone
than just setting it correctly in the source code where it should be.

But then, it is not for the builder to classify anything as GA or
not. That is a decision for the person making the release.

Either way, there is nothing to stop me taking a snapshot of 8u-dev
today and building it as 8u292 with the fcs milestone.  What we can do
is help people who want to do the right thing by giving them sensible
defaults in the source code that reflect what is already present in
Mercurial tags and source tarball filenames.

-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
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


More information about the jdk8u-dev mailing list