> How did jdk12 suddenly appear ? How did that happen in trunk ? > While 2.0 was trunk, it must have started off as jdk11 only. During trunk dev > jdk12 was worked on, and the runtime aspect of jdk12 backported to 1.0. I'm having a hard time tracking what you're saying here. =/
Another way of phrasing what's listed above is: ------------------------------------------------- When a new JDK goes LTS, we prioritize: 1. Moving trunk to build and run on that JDK, dropping others 2. Upping language level on trunk to that JDK 3. Adding support to run on that JDK to all supported GA releases We'd need to merge 1 and 3 atomically to preserve the "you can upgrade from a GA version to newest GA on the same JDK" property. The above would also mean we'd add the ability to run all GA versions of C* on the most recent LTS JDK as soon as it's supported on trunk during a patch release cycle. Which I think is probably fine? A requirement for the above from a CI / confidence perspective would be: 1. Trunk passes all CI on the new JDK (including potentially new harry stress and simulator test pipelines) 2. Other GA branches pass all CI running on the new JDK > This means that jdk12 runtime support was added to 1.0 before 2.0 was > branched or released. I think this is addressed w/the above clarification. wdyt? > 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? On Wed, Jun 11, 2025, at 4:05 AM, Mick Semb Wever wrote: > Pushing a little for added clarity, see inline, while totally fine with this > approach. > > > >> Then we release the next C* version; for sake of illustration let's assume a >> new JDK LTS 12: >> • C* 2.0 / 12 / 12 / 12 >> • C* 1.0 / 11 / 11+12 / 11 >> > > How did jdk12 suddenly appear ? How did that happen in trunk ? > While 2.0 was trunk, it must have started off as jdk11 only. During trunk dev > jdk12 was worked on, and the runtime aspect of jdk12 backported to 1.0. > > This means that jdk12 runtime support was added to 1.0 before 2.0 was > branched or released. > > 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 ? > > It's a minor detail thick in the weeds, and maybe easily addressed if/when we > hit it, but we should be realistic to our dev input being not always constant > and reliable. > > >
