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.
