+1 for me on the proposal to require a 2.361 baseline. I'm in favor of a late 2022 (after 2.375.1 of course) as the end of year is usually spent on low activity so it will let plugin maintainer some time to discover and fix any issues caused by this change.
> Independently of that, we can consider switching the default JDK for ci.jenkins.io `buildPlugin` from 8 to 11. I volunteer to make this change in the form of a draft PR to the jenkins-infra/pipeline-library until we are ready to go. Damien Le mardi 29 novembre 2022 à 10:19:10 UTC+1, ullrich...@gmail.com a écrit : > +1 from me as well (after release of 2.375.1) > > > Am 28.11.2022 um 19:50 schrieb Basil Crow <m...@basilcrow.com>: > > > > Historically we have supported old baselines for a long time in the > > build toolchain. The current build toolchain supports baselines as far > > back as 2.249. This provides a high degree of flexibility for plugin > > maintainers and ultimately end users. > > > > Sustaining this level of compatibility across complex transitions like > > the move to Java 11 and Jetty 10 comes at significant build toolchain > > complexity, either in the form of conditional logic in a single-branch > > build toolchain scheme (the current status quo) or in the form of > > multiple branches (a hypothetical scenario). For example, the test > > harness needs to support Java 8 in order to support 2.249, the need to > > support Java 8 means the test harness cannot move to Jetty 10 (which > > requires Java 11), and the test harness' continued use of Jetty 9 > > requires core to retain support both Jetty 9 and 10 (even though only > > Jetty 10 is used in production use cases). Similarly, conditional > > logic is required to set the Maven compiler release version to 11 for > > plugins when newer baselines are in use, and even then that > > conditional logic tends to trip up IDEs. > > > > For these reasons, it is desirable to require a baseline of 2.361 or > > later (and therefore Java 11) for plugins in the build toolchain > > sooner rather than later. The advantage is that this allows us to > > simplify and clean up conditional logic that is increasingly becoming > > less relevant and a maintenance burden. The disadvantage of requiring > > a baseline of 2.361 or later for plugins in late 2022 or early 2023 > > (as opposed to our usual timeline of e.g. late 2023 or early 2024) is > > that it is more of an imposition on plugin maintainers and users of > > older LTS lines. I believe that the advantages outweigh the > > disadvantages and that we should do this sooner rather than later, > > ideally in late 2022. > > > > If the consensus is that we are OK with requiring a baseline of 2.361 > > or later for plugins in late 2022 (i.e., after the release of 2.375.x > > LTS) or early 2023 (i.e., after the release of the next major LTS line > > after 2.375), then I explicitly commit to implement the change in the > > plugin parent POM (e.g., with regard to Java 8), test harness (e.g., > > with regard to Unicode properties files), HPI plugin (e.g., with > > regard to the Maven compiler release version), core (e.g., with regard > > to Jetty 9), annotation indexer, symbol annotation library, version > > number library, and access modifier library, noting in the release > > notes for all eight (8) components that this is a breaking change for > > plugin maintainers and that plugin maintainers must use a baseline of > > 2.361 or later when upgrading to the latest build toolchain. > > > > If you are in favor of requiring a baseline of 2.361 or later for > > plugins in late 2022 or early 2023 and with me implementing this > > transition in the manner described, please reply with your timeline > > preference (either late 2022 or early 2023). If you are in favor of > > maintaining a stable branch of the abovementioned eight (8) components > > for older LTS lines, please reply stating whether you are willing to > > do the implementation and release work (noting that I explicitly > > decline to do this implementation and release work). If you are in > > favor of any other proposal, please reply stating the alternative > > proposal and whether you are willing to do the implementation work. > > > > Thanks, > > Basil > > > > -- > > 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-de...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjo4AV%3DuY-f1R%3DjTFTfwe-m8TdxONt4Ly7yhU3JpPTJj6w%40mail.gmail.com > . > > -- 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/a43bb5c8-c6a2-4ea3-b138-293cbd750961n%40googlegroups.com.
