I am definitely opposed to trying to continue to “support” 8 if and when we use 11 as a baseline for core. Let us be clear about what we require and test against, so that we do not have a combinatorial explosion of platforms. Plugins can be switched to run 11 in CI over the course of a few months, and upgraded to `-source 11` as soon as they decide to pick a new `jenkins.version`. (There is a bit of infrastructure work needed for all this.)
Basing decisions on what portion of users currently run on 11 seems circular. The interesting question is what portion of users _cannot_ run 11, for example due to some corporate mandate, and so would actually refuse to upgrade Jenkins. This is harder to measure, of course, but we can try. I do not _think_ there is any problem running an agent on 11 while the controller is on 8, or vice-versa, but it bears testing. Last I tried using 11, there was still a lot of polish missing. The agent printed a bunch of warnings about use of JDK internal classes. IMO we should not be promoting use of a 9+ version until we can be assured that no such warnings are printed when using testable features of core or common plugins, perhaps by running `plugin-compat-tester` and `acceptance-test-harness` with a JVM flag to turn on strict mode. (JEP-228 means we are now on a version of XStream which at least claims to get this right!) Note that AdoptOpenJDK intends to support Java 8 for considerably _longer_ than 11. And we should be at least testing against newer versions including previews of 17 when they become available, lest we move to 11 just as it is becoming obsolete. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0C3GO1SiAYzhN2Zjp6x6_nk6t03LW8n_1kim5xMC4ZDQ%40mail.gmail.com.
