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

[Andrew John Hughes]

On 05/06/2019 09:08, Langer, Christoph wrote:
> 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.
> 

Right, but I'm still wondering why. What is the benefit of filing a new
bug each time, for something which isn't really a bug?

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

We don't have it any place at the moment. That's kind of the point. If
we did, the same would apply for the update version & milestone, but you
don't seem to have the same objection there.

 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?

It'd be a nice touch, but it's fundamentally flawed when you don't have
Mercurial and/or the repository metadata available. We're not really
worried about the version output of builds made by developers, but of
those made by downstream distributors who build from a source code bundle.

We've actually had functionality in IcedTea for years for it to report
the exact JDK & HotSpot revisions that were built, but it's rarely
exercised, because it requires building from a Mercurial checkout with
Mercurial available on the build system, not from a compressed source
code bundle.

> 
> /Christoph
> 
-- 
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