Thanks for the PR @jonesbusy ! Looks a good idea.

The SRE in me says it is a good idea, but this is a collective decision to be made: are you ok to add this to the agenda of an upcoming SIG platform please?

=> additionally, it require a bit more work, as we should identify the plugins which will be broken to make sure we don't have bad surprises. Maybe we can accept that this "work" would be "merge this PR, trigger build on all ci.jio plugins and check which one are failing". This won't be exhaustive (as not all plugins are using ci.jio) but it would cover the most used plugin as far as I know.

Any thoughts other key players here @basil @MarkEWaite @daniel-beck @Wadeck @jglick @jtnord @Poddingue @timja @mawinter69 @slides ?

(maybe also start discussion / or link to existing one on the developer mailing list to have a wider audience as this repo might not be followed by key maintainers)

Sure thanks.

Also from what I identified is that a lot of outdated plugin using implicit buildPlugin JDK 8 are already faling. (All that still depends on Jenkins 1.x and parent 1.x or 2.x. Because some old parent pom have unfixed range version for some tooling [1, ] like maven plugins. Which will pull a minimum required JDK version 17 for such plugins. (I don't remember if it's the hpi or some other tooling).

So a build that would have worked few years ago would fail now without any change

So for me the situation is that bumping to Java 11 as a default will not make the situation worse

I will try to find example or such unfixed version range on older plugin pom.

are you ok to add this to the agenda of an upcoming SIG platform please?

I'm unsure if many of the involved people would attend that, I think either this PR or the mailing list would be most appropriate.

Answered https://groups.google.com/g/jenkinsci-dev/c/pjfvsMw-EMM

I have a list of plugins without a Jenkinsfile, plugins using an old Java version, and plugins not defining a Java version, just in case. 🤷

Those plugin are difficult for non-maintainer or non-administrator to modernize because it require the Jenkinsfile to be replayed

if you are attempting to modernise a plugin though, why would you use a java 11 version over java17 which has been required since 2.462.1?

How is this different to a non maintainer modernising a plugin to support java21 / jakartaee or the like where the maintainer has explicitly put in versions?

Personally I am of the belief that the version should be explicit and the default should eventually die, and this PR makes this harder by keeping it alive. Whilst that makes it harder for non maintainers, unless we are constantly bumping the default (for java17 then java21) then we are just kicking a can down the road for the few that have not explicitly set the version.

I am not going to die on this hill.

though

Yes but at least PR that modernize them will not

if you are attempting to modernise a plugin though, why would you use a java 11 version over java17 which has been required since 2.462.1?

If I'm not wrong Java 17 is required since 2.479.1. We still recommend 2.452.4 which is still compatible with Java 11 (https://www.jenkins.io/doc/developer/plugin-development/choosing-jenkins-baseline/#currently-recommended-versions) https://www.jenkins.io/doc/book/platform-information/support-policy-java/#running-jenkins-system

The reason we have an archetype Jenkinsfile with Java 17 and 21 is because we didn't detected issues that would occur on Java 11 and not 17 or 21 (This save also cost by removing a matrix from the build).

Don't get me wrong, I think those implicit version are bad and must be removed at some point.

The point is with a default on Java 8 it make it difficult to align them to the archetype and would cause many build issue for non-maintainer when opening PR (Which lower a lot chances for a PR gets merged)

My opinion is that this PR is a step further not a step back

If I'm not wrong Java 17 is required since 2.479.1. We still recommend 2.452.4 which is still compatible with Java 11 (https://www.jenkins.io/doc/developer/plugin-development/choosing-jenkins-baseline/#currently-recommended-versions) https://www.jenkins.io/doc/book/platform-information/support-policy-java/#running-jenkins-system

Yup, my mistake.

Don't get me wrong, I think those implicit version are bad and must be removed at some point.

Mmmh, asking the question naively (as in: I don't see immediate obvious reason not to but I might be missing a LOT of things) but: since we are batch-modernizing plugins (with bunch of PRs cross repositories with corresponding tooling and processes), why not removing the default value and making builds to fail with an error message "please specify explicit version")?

If we have to break (or we already have them broken today) plugin builds, why not doing it once for all?

Makes sense to me. 🤔
Better check the list of plugins building with the default version just in case...

Make sense, but perhaps it could be the next steps (maybe when 2.479.1 is the minimum recommended version ?

Maybe a less "big bang" approach

1. We switch to default Java 11 on infra library
2. We deprecate implicit settings and communicate (without faling build yet)
3. We modernize as much plugin as possible using minimum Java 11 and Jenkinsfile archetype (Java 17 and Java 21) so that PR doesn't fail and anyone including non-maintainer can contribute
4. We remove implicit settings, and fail build

What do you think?