Transition to 2+2+2 Java Support for Jenkins

[Mark Waite]

Java releases are delivered every 6 months with a long term support release every two years as announced in a September 2021 blog post.  The release cadence is described in more detail in another blog post.  The OpenJDK project and Eclipse Temurin project both support their long term support releases with security patches for six years.

The two year release cadence with a six year support life means that three Java LTS releases are officially supported at any point in time by the OpenJDK project and the Eclipse Temurin project.  Jenkins developers would like to generally support two Java LTS releases rather than three LTS releases in order to reduce overhead from supporting Java releases.

In order to limit Java support to two LTS releases, I propose that the Jenkins project adopt a “2+2+2” model where a new Java LTS release is supported for two years, then becomes the minimum required Java version for two years, then is unsupported for two years.  In the last two years, new Jenkins releases will not run on that oldest supported Java version.

A diagram is provided to describe the transition from our current model to the “2+2+2” model.

The diagram shows that as part of the transition, Java 17 will be the minimum required Java version for only 12 months and Java 21 will be the minimum required version for only 18 months.  Java 25 and later will be the minimum required version for 24 months.

The “2+2+2” pattern balances the needs of large scale Jenkins users for predictability and stability and the needs of Jenkins developers for less maintenance overhead.

After a week or two of discussion in the Jenkins developer mailing list and the Jenkins user mailing list, I plan to submit this as a Jenkins Enhancement Proposal.

More details are available in the Google Doc.

Thanks,

Mark Waite

[Mark Waite]

I've created a Jenkins Enhancement Proposal based on this draft.  Comments are welcomed at https://github.com/jenkinsci/jep/pull/400 

[Mark Waite]

Two diagrams have been added to the Jenkins Enhancement Proposal.  One diagram shows a single Java version (Java 25) to highlight the lifecycle of a single Java version in the Jenkins community.  The other diagram shows the transition across multiple Java versions.  The pull request includes the discussions.

The duration of the alert period that precedes the transition from one minimum Java version to the next minimum Java version is still being discussed.  The current implementation in Jenkins core provides begins notifying 18 months before the change and then notifies again 9 months before the change.  James Nord feels that it would be better to notify 12 months before the change and refresh 6 months before the change.  The pull request conversation has the details.

Tim Jacomb (a JEP editor) has agreed that the proposal is ready to be assigned a JEP number and to enter "Draft" state.  I'll plan to do that within the next few days.

Assigning a JEP number does not prevent us from correcting or improving the JEP.  Changes, corrections, and improvements are allowed to draft JEPs.

Mark Waite