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
[email protected]
<mailto:[email protected]>.
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
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/515af80f-6cc3-41ca-ba69-8e50ab77ee0b%40redhat.com.
