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

On Monday, September 25, 2023 at 7:18:40 AM UTC-6 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].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/56c75c6e-6b94-47cb-8659-a3e1c9df449fn%40googlegroups.com.

Reply via email to