-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update default Jenkinsfile to include Java 21 #651
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we get a spreadsheet going for implementing this in, say, the top 100 or 200 plugins at least? I'm willing to help
=> https://docs.google.com/spreadsheets/d/1RbeVLsyp03JP1qvM9jVcpZU2CPvOlI-Wffmez7u4IfY/edit?usp=sharing |
Commensurate with the effort that you and Mark have already expended, I have filled in about two dozen rows in the spreadsheet.
A prerequisite for my approval of this pull request was an effort to migrate the ecosystem, but 170 rows of this spreadsheet are still red. |
Rather recommend updating Linux from 17 to 21 but leaving Windows on 11, since we still support 11 (and I presume expect to still support it for some time), unless and until Jenkins core drops 11 support and plugins begin picking up that baseline. Running all three seems unnecessary in terms of load on the CI system and I do not see much advantage—it is not very likely that a change would introduce a regression on 17 but not either 11 nor 21. |
That recommendation ignores the staggering implementation cost of multiple ecosystem-wide migrations: |
The previous comment appears to asssume that you are doing that migration, however a plugin author can do that as and when their plugin bumps to a core requiring java 17 as a minium. No staggering extra cost in incurred here, if an author is bumping core versions. I agree with Jesse there is no reason to drop Java11 here. Or if you are only interested in new plugins to use the same arguments against a plugin author in. Similar yet unrelated code changes |
We have to stop assuming that plugin authors are going to do these migrations "someday." The fact is that they aren't, and these incomplete migrations are becoming massive technical debt that falls on whoever happens to be next working on some unrelated change. And it is turning people away from plugin development:
When changing the archetype, we have a responsibility to evolve the "important" (for some definition of "important") parts of the ecosystem along with that change.
Unless you are going to be actively participating in the migration effort in a significant way, I think this opinion carries limited weight. |
https://www.jenkins.io/doc/developer/publishing/new-plugin/ uses the plugin archetype to generate a Jenkinsfile that tests with Java 21 on Linux and Java 17 on Windows. A discussion of the reasons for that configuration is available in jenkinsci/archetypes#651 Let's have the documentation use the same technique as is used in the plugin archetype.
https://www.jenkins.io/doc/developer/publishing/new-plugin/ uses the plugin archetype to generate a Jenkinsfile that tests with Java 21 on Linux and Java 17 on Windows. A discussion of the reasons for that configuration is available in jenkinsci/archetypes#651 Let's have the documentation use the same technique as is used in the plugin archetype.
Fixes #650