[jdk17u-dev] RFR: 8283911: DEFAULT_PROMOTED_VERSION_PRE not reset to 'ea' for jdk-17.0.4

[Andrew John Hughes]

On Wed, 30 Mar 2022 17:32:24 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> I'm on the fence about this. On the one hand it indicates when we have an `EA` build (if we happen to define EA for update releases too) in the sources. On the other hand this would be prone to error to switch to "GA" mode at the right time. Would this need a separate bug when switching back to GA? Given that most downstream distributors probably don't rely on this (what would they have done up to this point if they did?) anyway, I'm questioning its usefulness. No strong feelings though.
>
>> I'm on the fence about this. On the one hand it indicates when we have an `EA` build (if we happen to define EA for update releases too) in the sources. On the other hand this would be prone to error to switch to "GA" mode at the right time. Would this need a separate bug when switching back to GA?
> 
> The whole process of switching back and forth between EA and GA is error-prone, but, as far as I can see, unavoidable if one wishes to make pre-release builds rather than just moving directly from one GA release to another. Not having the value in the JDK itself doesn't solve the problem. It just makes it more likely that downstream distributors get it wrong, especially if they are not active in JDK development themselves. Having an inaccurate value, as we do now, is even worse.
> 
> I think a similar argument could be made for the other values in that file; they also require someone to remember to update them at certain points in the release cycle, but having one authoritative source helps all distributors. We have done without them in the past and I think having them in the JDK sources has improved things.  We can certainly make the process clear by documenting what these changes are and when they need to be made in the release process documentation.
> 
> You may remember that there was a mishap in the past, when Debian was publishing EA code as a GA build. At that time, we adapted the Fedora & RHEL RPMs to handle EA & GA builds with appropriate naming. When I spotted the addition of `DEFAULT_PROMOTED_VERSION_PRE` by Oracle - who I guess from the logs have similar issues with switching this back and forth - I updated our RPMs to check their value against the value in the sources.
> 
> This PR arises from that check doing its job, though in the opposite direction to what I expected when I wrote it. I was packaging 17.0.3+1, correctly changed the build to EA mode... and then it failed because the build correctly detected a mismatch and said "Hey, this should be GA!"
> 
> I think there is no need for jdk<x>-dev to ever be anything but `ea`. The switch to `<empty>` ('ga') should happen as part of the final changes along with the jdk*-ga tag in the jdk<x> tree, and then we should avoid merging that change back into -dev. Yes, it would need a bug, but then we also have bugs for the version bump. It can be reviewed and approved in the same manner as the other security fixes, without having to go through the public process.
> 
>> Given that most downstream distributors probably don't rely on this (what would they have done up to this point if they did?) anyway, I'm questioning its usefulness. No strong feelings though.
> 
> The field was only added in May 2019. I only spotted it myself when updating to OpenJDK 16 last February. It's not been publicised, OpenJDK 17 is the first time it has been in an LTS release and 17.0.3 is the first 17u release where the value is being maintained by someone other than Oracle. Our logic has not caught it for 17.0.1 & 17.0.2 because we've hopped from GA release to GA release.
> 
> So the question for me is not whether distributors already rely on it (we haven't had much opportunity to, it being either unavailable or wrong), but whether it is going to be maintained enough for us to rely on it. I think the check we have is useful for keeping the status in sync between the sources and the RPM. It may well help those who are more divorced from the JDK development process even more in obtaining their downstream builds. I'd actually prefer that `configure` used it, but I can see there is resistance to that, so it's not something I'd push for. I'm happy for the value to remain as a helpful hint.
> 
> Either way, I think having an inaccurate value in there is helpful. If we don't wish to update this value in sync with JDK updates development, it should be removed from the updates tree.

> Hi @gnu-andrew,
> 
> so far, DEFAULT_PROMOTED_VERSION_PRE has not been actively used in OpenJDK update releases. It seems it has had a purpose only within Oracle's infrastructure. Hence, I removed it from 11u a while ago with [JDK-8269415](https://bugs.openjdk.java.net/browse/JDK-8269415).

Well, that set the value to empty, which apparently means "ga". It didn't remove the field. I had no idea it had been backported to 11u before I found that change yesterday and I'm still surprised it was. As with 17u, it should really be either maintained or removed altogether.

> If we now start using it, it is a slight change in process that all maintainers have to be aware of. E.g. add "ea" when starting an update release with the version bump or keep it when merging back from the rampdown branch and make sure it gets removed with a final "ga" commit.

I think the simplest route is to change it at the same time the integration tree is tagged `-ga` and then drop it when merging this back to `-dev`, either as part of the merge changeset or a separate one. I mistakenly associated it initially with the start of a release cycle, but the transition there is from an EA build of release `n` to an EA build of release `n+1`. The integration tree is really the only one that needs to see the empty value ("ga").

My preference is to have this value maintained and I would also like to backport it to 8u so we can handle at least 8u, 11u & 17u consistently with this value. I'd maintain that value in the 8u promotions & merges, and yourself and @GoeLin would need to do so for 11u & 17u. Azul are of course welcome to maintain it as well for 13u & 15u, and I believe Oracle already do so (primarily for pre-releases of major versions).  However, if the two of you don't want the additional work of maintaining this, I'm happy to achieve the same consistency by just dropping the field from the 11u & 17u update releases.

As I outlined in my reply to @jerboaa above, my issue at the moment is we have a check we implemented during the OpenJDK 16 pre-release period to confirm that the value of `DEFAULT_PROMOTED_VERSION_PRE` in the source code matches what we expect in our RPMs and this is now failing because the EA source code has the same empty value as the GA source code. So I need to make a decision as to whether we abandon this check, restrict it to only where the update version is 0 or fix the value at source. I've applied the patch attached to this PR for now for 17.0.3, but that's not a sustainable solution for future update releases.

-------------

PR: https://git.openjdk.java.net/jdk17u-dev/pull/307