On Sat, May 11, 2024 at 1:34 AM Ivan Fernandez Calvo <kuisathave...@gmail.com> wrote: > > Please do it, I am waiting for this change to update the SAML plugin to the > latest PAC4J version
Your wish is my command, Ivan! As discussed at the last governance board meeting, we are going to do it in a weekly release before the end of June. I plan to release a new version of jenkinsci/pom with maven.compiler.release set to 17 and adopt it in core and all core components, producing a weekly release that requires Java 17 bytecode. I will try to retain Java 11 bytecode in executable.Main to print a decent user-friendly error message on the controller on Java 11 (no such plan for agents, though). The plugin parent POM will continue to support cores with both Java 11 and 17 bytecode (i.e., its minimum jenkins.version will not change) for a little while longer. The value of maven.compiler.release will default to 11 but will be dynamically reconfigured to 17 during the build when jenkins.version is set to a core with Java 17 bytecode. This should even work fine in IntelliJ this time around thanks to https://github.com/jenkinsci/maven-hpi-plugin/pull/578 (as long as at least one Maven build has been done prior to importing the project in IntelliJ), though developers should still exercise caution when upgrading libraries to Java 17 bytecode due to Enforcer's "EnforceBytecodeVersion" check being somewhat crippled during the transition period (as described in https://github.com/jenkinsci/maven-hpi-plugin/pull/583). This transition period is similar to the last one we did when we required Java 11, but it should be slightly smoother due to improved IDE support. FTR we had the same gap with Enforcer last time around and a bug or two slipped through during the transition period, so we need to be particularly vigilant about upgrading libraries until the transition period is over. The astute reader will notice that I wrote "I plan to release a new version of jenkinsci/pom with maven.compiler.release set to 17 and adopt it in […] all core components" (including the test harness) as well as "the plugin parent POM will continue to support cores with both Java 11 and 17 bytecode […] for a little while longer", two statements that are seemingly in contradiction due to the fact that a test harness with Java 17 bytecode will not be usable in a plugin parent POM that continues to support cores with Java 11 bytecode (i.e., maven.compiler.release set to 11). How is this contradiction to be resolved? By creating a backport branch of the test harness that continues to be based on Java 11 bytecode, and using this backport branch in the plugin parent POM until we decide to drop Java 11 support in the plugin parent POM (most likely around the timeframe when Jetty 12 EE 9 is delivered in LTS). This means that every change to the test harness will need to be backported to become available to plugin parent POM releases—painful in the short term, but the idea is that this phase will not last more than a few months. Meanwhile, on the default branch of the test harness, we hope to soon deliver functionality to support both Jetty 12 EE 8 and Jetty 12 EE 9, selecting dynamically based on the core in use. This will be explained further in a forthcoming JEP, and it will allow plugins with tests that rely on Jetty APIs to begin migrating to Jetty 12 in advance of the rest of the ecosystem. I am planning to follow a lazy consensus approach with this plan. If nobody objects to this lazy consensus decision by the end of next week, I will consider the matter settled and start executing on the plan the week after that, with a weekly release that requires Java 17 delivered by the end of June. -- 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/CAFwNDjqdkRnmmAMfoFi%2BaJC0uSeWw6OL7GdKKhnD43wxiHGgRQ%40mail.gmail.com.
