Your proposal sounds great to me, and thanks for volunteering to implement the changes. I think a late-2022 timeline (sometime after 2.375.1 has been released) makes sense—if there is some advantage in waiting longer, I do not get what. The only likely drawback for plugin maintainers who deliberately wish to stay on a pre-2.361.x baseline is that Dependabot (if configured) will offer `plugin-pom` updates that fail CI builds, which is not so bad since the release notes will explain why, and the PR and its replacements can simply be ignored indefinitely. (And of course you will not get access to new stuff in the toolchain, but that seems fair.)
Independently of that, we can consider switching the default JDK for ci.jenkins.io `buildPlugin` from 8 to 11. Even if your plugin supports older baselines and Java 8, running the build on JDK 11 is typically fine, since `-release 8` will ensure the right bytecode and even prevent the infamous `ByteBuffer` problem. The likely issues: you will lose Java 8 test coverage (while gaining 11 test coverage, which is more important!); and occasionally some tool like `javadoc` will be stricter (in a way you ought to fix anyway though you might have preferred to take your time). -- 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/CANfRfr1mdb5zZx7%3D%2B2M%2BgtUrCMXtfCQcJ406WhvQojhx5NTbXw%40mail.gmail.com.
