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