JDK 25.0.2 base repository

[Lindenmaier, Goetz]

Hi Rob, 

I would appreciate a lot if there were tags in the open. 
It would be great if the changes you tested could be tagged
up to rdp2.

You might want to tag whatever you merged to your internal
space and built with something like jdk-25.0.2+open<build>.
And finally having an rdp2 tag would be great!

Best regards, Goetz. 


> -----Original Message-----
> From: Robert Mckenna <rob.mckenna at oracle.com>
> Sent: Wednesday, December 17, 2025 2:19 PM
> 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