JDK 25.0.2 base repository

Wed Dec 17 13:31:19 UTC 2025

Hi Rob,

thanks for shedding some more light into that.

So you obviously also merged in the version bump change (6a410a8a1a53d41dac64cfa98dc7618d80b6ca74) and had to back that out... 😊

Well, yes, it's definitely something where the process could be improved. I would suggest that there should be an always open master branch and then stabilization branches for the releases (e.g. 25.0.1, 25.0.2 etc.) which would then make it obvious. It would also be ok if you switch to the jdk-<nn>u and jdk-<nn>u-dev model as we use it later on in OpenJDK.

What happened to the discussion that JDK Updates releases should also use one single repository with branches for the releases, just as head development does?

Cheers
Christoph

> -----Original Message-----
> From: Robert Mckenna <rob.mckenna at oracle.com>
> Sent: Mittwoch, 17. Dezember 2025 14:19
> To: Shipilev, Aleksey <shipilev at amazon.de>; Langer, Christoph
> <christoph.langer at sap.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; jdk-updates-dev at openjdk.org
> Subject: Re: JDK 25.0.2 base repository
> 
> 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