> it might not always be smooth sailing – we might be losing some agility. But > let's give it a go and find out. Yeah, good point. When I bring it to VOTE I'll see if I can't massage the wording a tiny bit around our intent to get to latest LTS support on trunk but retain flexibility to wait if during a burn down to a release, if problems are discovered, if certain things are deprecated and necessitate change or waiting on lifecycle, etc.
The directional statement of intent - we want to be on the latest JDK on trunk when reasonable so the next release supports latest LTS - is where I think the real value is. Leaves a lot of flexibility though on timing. On Wed, Jun 11, 2025, at 4:09 PM, Mick Semb Wever wrote: > You replied accurately to what i said, we're aligned. One point to continue > is below… > > >> >>> And then, will the confidence of jdk12 in trunk be complete before its >>> merge, and at what point can jdk11 safely be dropped ? >>> >>> The action of dropping jdk11 in trunk is just a one-liner in build.xml >>> (actually code removal can happen later), but it's a commitment from us >>> that jdk12 will be production ready. If attaining that confidence happens >>> post-merge then there's a window where there is a chance we end up having >>> to cut 2.0 with 11+12 ? >> This is an interesting question. Do we have sufficient confidence that when >> an OpenJDK LTS release hits it's stable? Assuming we can run our entire >> suite of CI (and add in a future harry stress, a harry soak, and simulator >> into the mix), what other bar for readiness do we have? >> > > > CI pre-commit doesn't catch everything. We can assume new LTS jdks come out > reasonably safe now, but we've also seen the time it takes to stabilise > something post-merge. Whether it's flakies, test variants that weren't run, > especially if we start moving tests to only post-commit weekly runs, or just > access to people available to be running harry. Or bugs reported by users > running the new jdk on the older branches that come in late creating a hold > up (and forcing a commitment: because there's no alternative jdk now; on) > trunk. > > I don't have any objections here, just pointing out it might not always be > smooth sailing – we might be losing some agility. But let's give it a go and > find out.
