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

Wed Jun 5 08:08:48 UTC 2019

Hi,

> > Nah. Multi-mapping commits to issues was always problematic to me.
> >
> 
> Can you elaborate on this? What are the disadvantages?

Probably Aleksey has its own arguments but I'd prefer having separate bugs for each version bump as well - same as in jdk11 updates.

> As far as advantages go,
> 
> * Every such changeset can easily be found using that bug ID
Is that an advantage? Over time you'll find dozens of commits with the same commit message. You have to walk through each one to see what's the actual content.

> * There is no need for a separate approval process for each version bump
As it seems to have been agreed for JDK 11 updates, we'd skip the approval process for this task now. This should be the agreement for JDK8u as well, I suggest...

> * The change serves as a good test case that hgupdater has been correctly updated
Yes, but that has nothing to do with whether it's one bug or a new bug each quarter.

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

I agree that for the unaware builder, by default a version number should be generated that correctly reflects the version of the source drop from which it was build.

So we're completely in agreement that the default milestone should be ea - to not incorrectly mark a custom, version unaware build as ga.

Furthermore, as we have it in upstream already, we should set the correct update version by default (such as 8u222 or 11.0.4) which will require a quarterly bump. This is already implemented in OpenJDK updates >=11 and it would be good if OpenJDK 8 updates could follow the same process.

Now as for the build number: I also agree that it would be desirable if the correct build number was shown by default. The source of truth for the build number is the (highest) tag in the repository though. I think we should avoid having this information in more than one place. I think it would be a good suggestion for upstream jdk/jdk as well to calculate the default build number by evaluating the repository tags. If you agree with that, I could open an issue and try to make an enhancement which can then be backported. What do you think?

/Christoph