JDK 25.0.2 base repository

[Robert Mckenna]

Hi folks,

I've just attempted to add a jdk-25.0.2-openrdp2 tag before being reminded that skara has a very limited interpretation of what it considers to be a valid tag. I'll see if I can figure out something here.

The last commit that was merged into stabilization was 796f2b42b07c150602acc98fe1a9ad69c5bc5d0d.

We should probably have a wider conversation on how to tackle this going forward. The three potential solutions I can think of are:

- use a predetermined tag
- rename the initial repo to jdkXXu-dev in order to make its purpose clearer
- create stabilization branches in jdk25u.

Branches would be my preference.

    -Rob
 

________________________________________
From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.org> on behalf of Shipilev, Aleksey <shipilev at amazon.de>
Sent: Tuesday 16 December 2025 14:30
To: Langer, Christoph; Lindenmaier, Goetz; jdk-updates-dev at openjdk.org
Subject: Re: JDK 25.0.2 base repository

On 16.12.25, 14:33, "Langer, Christoph" <christoph.langer at sap.com <mailto:christoph.langer at sap.com>> wrote:
> And, Aleksey, regarding the commits that you cited which would be in the jdk-25.0.2 to be released, it's also not completely correct [...] This probably applies to all commits until the one that you cited [...] However, if you want to be sure, you need to check each item in JBS whether it went into the release.

I only mentioned the commits that would appear in downstream build *in addition* to what would actually ship in normal 25.0.2 release, in case a vendor decides to build/test from jdk25u, (mistakenly) thinking it is only 25.0.2. Only to discover near the GA date that there is a difference beyond security patches. I cross-checked all issues from my "product fixes" list, and all of them are 25.0.3 only in JBS. That list calms me down a bit, actually, because there seem to be nothing on product side that would cause myself to say "Oh wait, oh no, this should wait for 25.0.3; also it does not readily invalidate 25.0.2 testing".

But I think you as maintainers might also need to look at it carefully and decide that the risk -- if anything like that actually happens -- is low.

> Generally, a downstream vendor who wants to test an Oracle maintained release from the jdk<nn>u repository always has to find the tag that he would need to base his work on. And to be able to know more about the bits that are actually in the release, they need to take part in the vulnerability group where the exact bundle is shared in advance.

I understand the bit about the security patches: they would have to stay in private repository until embargo date expires. At the same time, I do believe that the bulk of the release contents (regular backports) should be done in clearly demarcated public repositories. And we already have that in community-maintained releases: current split between jdk25u and jdk25u-dev does that nicely for us. We should just stick to the rule that no release "N" backports happen in jdkXXXu until we start stabilizing for that release "N". That looks completely doable, we just need to decide to keep doing it :) Maybe write it down somewhere in jdkXXXu handoff checklist, if there is any?

Sure, that does still not solve the problem with additional (critical) backports after the private stabilization branch is cut, but at least it prevents the accidental leakage of backports in downstream build/test pipelines. In the ideal world, I would have liked to see the bulk of 25.0.1/2 stabilization branch being not private, but that ship had already sailed. It would be extra nice if JDK 29u started with jdk29u (29.0.1 initially) and jdk29u-dev (29.0.1 initially, then switched to 29.0.2) from the get-go, so we don't get into any non-nice situations like these again.

Thanks,
-Aleksey




Amazon Web Services Development Center Germany GmbH
Tamara-Danz-Str. 13
10243 Berlin
Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
Sitz: Berlin
Ust-ID: DE 365 538 597