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

Langer, Christoph christoph.langer at sap.com
Tue Jun 4 07:38:35 UTC 2019


Hi,

I agree to Aleksey here. The update version should be set once per quarter (like we bump the 11u version every time after final branch 11u-dev->11u) and the default milestone should be -ea.

But I would definitely not increment the (default) build version via a code patch every week. Setting the right build number is the task of a downstream vendor's build system, e.g. by looking at the repo tags.

Best regards
Christoph

> -----Original Message-----
> From: jdk8u-dev <jdk8u-dev-bounces at openjdk.java.net> On Behalf Of
> Aleksey Shipilev
> Sent: Montag, 3. Juni 2019 19:30
> To: Andrew John Hughes <gnu.andrew at redhat.com>; 'jdk8u-
> dev at openjdk.java.net' <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
> 
> 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.
> 
> > 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
> 



More information about the jdk8u-dev mailing list