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

[Jiri Vanek]

Maybe a small narrowing.
The LTS every two years means that Oracle java will be following that. And that is beyond paywall.
The usptream openjdk is simply rolling with new jdk every half a year, and of it nothing is going to be LTS, unless somone to pick that particular repository and keep maintain that, and keep building that (here, eclisdpe adoptium will be
most likely building ever jdk repo which have maintainer). See eg AZUL maintaing LTS of JDK13 and few others...

Where it is likely that other java vendors will pick up the jdk repos, in alignment with Oracle LTS support, it is not strictly true. (eg see SAP recently dropped jdk11 support, and RH hadc to take it over).

Thanx for bringing this 2+2+2 model up.

J.

On 9/25/23 15:18, Mark Waite wrote:
> Java releases are delivered every 6 months with a long term support release every two years as announced in a September 2021 blog post <https://blogs.oracle.com/java/post/moving-the-jdk-to-a-two-year-lts-cadence>.  The release cadence is
> described in more detail in another blog post <https://blogs.oracle.com/javamagazine/post/java-long-term-support-lts>.  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 <https://docs.google.com/spreadsheets/d/1Gc-0yuYOD5u674qnxbPOWhCU5t9viCJukVj_9b-kwAw/edit?usp=sharing>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 <https://docs.google.com/document/d/1y3RVlniNmz-5Nd3LI-w58LDf760Ai7FqssP4zHuTv8U/edit?usp=sharing>.
>
> Thanks,
> Mark Waite
>
> --
> 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 <mailto:jenkinsci-de...@googlegroups.com>.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/2f4e2751-6765-4973-8a05-48d0a7fce8e5n%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/2f4e2751-6765-4973-8a05-48d0a7fce8e5n%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
Jiri Vanek Mgr.
Principal QA Software Engineer
Red Hat Inc.
+420 775 39 01 09

[Mark Waite]

On Thursday, October 26, 2023 at 8:12:02 AM UTC-6 Jiri Vanek wrote:

Maybe a small narrowing.
The LTS every two years means that Oracle java will be following that. And that is beyond paywall.
The usptream openjdk is simply rolling with new jdk every half a year, and of it nothing is going to be LTS, unless somone to pick that particular repository and keep maintain that, and keep building that (here, eclisdpe adoptium will be
most likely building ever jdk repo which have maintainer). See eg AZUL maintaing LTS of JDK13 and few others...

Thanks for the comment Jiri.  Much appreciated.

I'm relying on the statement on the Eclipse Temurin Release Roadmap where it says

> In addition, every two years since 2021 one feature release will be designated as a Long Term Supported (LTS) release. We will support LTS releases for at least four years.

Since Eclipse Temurin will support an LTS JDK for at least four years after its initial release, I think that the Jenkins project can rely on that.

Mark Waite

[Jiri Vanek]

> I'm relying on the statement on the Eclipse Temurin Release Roadmap <https://adoptium.net/support/#_release_roadmap> where it says

>
> > In addition, every two years since 2021 one feature release will be designated as a Long Term Supported (LTS) release. We will support LTS releases for at least four years.
>
> Since Eclipse Temurin will support an LTS JDK for at least four years after its initial release, I think that the Jenkins project can rely on that.

I see. That sounds like correct assumption. Only JDK will become LTS only and if only somebody pick it up. So yes, the statement is correct - We can be pretty sure that once per 2 years, at last one JDK indeed will be picked by any of
bigger java players. And if so, it is most likely being aligned with oracle.

Thanx for those additional details and sorry for noise.


J.

[Mark Waite]

On Thursday, October 26, 2023 at 9:29:00 AM UTC-6 Jiri Vanek wrote:

I see. That sounds like correct assumption. Only JDK will become LTS only and if only somebody pick it up. So yes, the statement is correct - We can be pretty sure that once per 2 years, at last one JDK indeed will be picked by any of
bigger java players. And if so, it is most likely being aligned with oracle.

Thanx for those additional details and sorry for noise.

Thanks to you as well for being involved and for sharing your concern.

Mark Waite