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

[Andrew John Hughes]

On 03/06/2019 18:30, Aleksey Shipilev wrote:
> On 5/31/19 6:28 PM, Andrew John Hughes wrote:
>> 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.
> 
> Nah. Multi-mapping commits to issues was always problematic to me.
> 

Can you elaborate on this? What are the disadvantages?

As far as advantages go,

* Every such changeset can easily be found using that bug ID
* There is no need for a separate approval process for each version bump
* The change serves as a good test case that hgupdater has been
correctly updated

I'm not suggesting it as general practice, but simply for this use case,
where, to be frank, a bug ID would not even be necessary, were it not
for this being enforced by the jcheck tool. I see no real difference
between these changes that update version information in the
version-numbers file and the changes that update version information in
the .hgtags file, yet the latter are exempt from jcheck.

>> 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.
> 
> I still think it should still be the burden of downstream builders to set the final metadata. I
> think setting the JDK_UPDATE_VERSION once per quarter is a fine balance between the changeset churn
> and accuracy. This also allows us to do a separate "bump" issue per quarter, which resolves the need
> for multiple changesets per issue?
> 
> For example, how 11u does it:
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/83a926bc11f1
> 
> Defaulting MILESTONE to "-ea" makes sure that default builds are specifically marked as EA, and
> downstream builders should be expected to change that when release happens.
> 
> In other words, I'd do:
> 
> --- old/common/autoconf/version-numbers	2019-05-31 17:13:05.463597676 +0100
> +++ new/common/autoconf/version-numbers	2019-05-31 17:13:05.295600273 +0100
> @@ -26,7 +26,9 @@
>  JDK_MAJOR_VERSION=1
>  JDK_MINOR_VERSION=8
>  JDK_MICRO_VERSION=0
> -JDK_UPDATE_VERSION=
> +JDK_UPDATE_VERSION=222
> +MILESTONE=ea
>  LAUNCHER_NAME=openjdk
>  PRODUCT_NAME=OpenJDK
>  PRODUCT_SUFFIX="Runtime Environment"
> 
> I also see no harm in doing the absolute minimum here:
> 
> --- old/common/autoconf/version-numbers	2019-05-31 17:13:05.463597676 +0100
> +++ new/common/autoconf/version-numbers	2019-05-31 17:13:05.295600273 +0100
> @@ -26,7 +26,9 @@
>  JDK_MAJOR_VERSION=1
>  JDK_MINOR_VERSION=8
>  JDK_MICRO_VERSION=0
>  JDK_UPDATE_VERSION=
> +MILESTONE=ea
>  LAUNCHER_NAME=openjdk
>  PRODUCT_NAME=OpenJDK
>  PRODUCT_SUFFIX="Runtime Environment"
> 
> -Aleksey
> 
> 

I'm aware of what 11u does, which is not without its own build
versioning issues.

What makes you think it is the "burden of downstream builders" to set
the version? I have built most packages from source over the last twenty
years, and OpenJDK is the only one I can think of where I have to tell
it what version I'm building. I have never had to do this with Linux,
glibc or gcc. I'm at a loss as to why the OpenJDK community would want
to make this some kind of strange test of their consumers, only to
publicly flame any who deign to get it wrong.

To my mind, if I download a source bundle labelled openjdk-x, then I
should be able to unpack it, run ./configure and make, and have a binary
that reports its version as x pop out at the end. Anything other than
this is frankly a bug.

Speaking as someone who does both the upstream work of tagging 8u, and
the downstream work for Fedora, RHEL & IcedTea, I'm baffled as to why it
is preferable for me to do a dozen identical version updates downstream
than it is to simply set it once upstream, where it should be.

I'm also aware that I have an advantage there in being involved in both
processes. Your average distro packager, who may have many packages to
update, may not be tracking the various intricacies of this project.
Indeed, why should they be, when no other package they maintain has to
be told what version it is?

I don't see either of your proposed solutions as an appropriate fix.
Having half the version information present by default and not the rest
just seems more confusing. It actually leaves the least discernible
information - the build number - down to the end user.

If the issue here is that this results in too many updates at high
frequency, then the problem is the process which creates release
information which is so often updated. The solution to that is not to
force tracking such information onto every downstream user, but maybe to
reconsider whether we want a "build number" (which doesn't actually
refer to a build) that changes every week.
-- 
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