Duration of Support for Jenkins LTS Versions

Hello Jenkins Community,

I have a question regarding the support timeline for Jenkins LTS versions. Recently, we installed Jenkins 2.452.x, but I noticed that Jenkins 2.462.1 was released on August 7th.

Does the release of the newer version mean that 2.452.3 is now out of support, and should we upgrade immediately to continue receiving updates? I would appreciate any clarity on how long Jenkins typically supports its LTS versions and when it’s advisable to upgrade.

Thank you in advance for your guidance!

The Jenkins security term provides security fixes for the most recent weekly release and the most recent LTS release. When a security fix is released as part of the first release of a new LTS line (as in Jenkins 2.462.1), the security team often also provides the same security fix for the last release of the prior LTS line (Jenkins 2.452.4 in this case).

If a security fix arrives on an LTS version that is not the first release of a new LTS line, then the prior line does not receive the fix. Jenkins 2.440.3 is an example of that pattern.

When running Jenkins LTS, you should plan to upgrade monthly.

When running Jenkins weekly, you should plan to upgrade weekly.

Hi Mark,

Thank you for your response!

Could you please clarify if Jenkins LTS versions have a defined end-of-life date? For example, at what point would Jenkins 2.440.3 be considered end-of-life, requiring everyone on that version to upgrade to a newer supported release? Understanding this would help us plan our upgrades more effectively.

Thanks again for your help.

Yes, you should upgrade immediately, especially because Jenkins 2.462.1 includes important security fixes.

I think that users of Jenkins LTS releases should upgrade monthly and users of Jenkins weekly releases should upgrade weekly. I think that is the healthiest pattern for users and assures that users have the latest fixes and improvements.

The Jenkins project documents don’t describe an end-of-life date. All of this is my thinking based on how I perceive end-of-life for Jenkins users. This is not something that the Jenkins project has stated explicitly.

End of life by date

Since the security team only provides security fixes for the most recent weekly release and the most recent LTS release, I think it is reasonable to act as though the end-of-life date for an LTS release is the delivery of the next LTS release, usually 4 weeks later. I think it is reasonable to act as though the end-of-life date for a weekly release is the delivery of the next weekly release, usually 1 week later.

This way of thinking about end-of-life is simple to describe. The current release reaches end-of-life when the next release is available.

End of life by fixes to security vulnerabilities

It might be stretched to say that the end-of-life date of a release is the date of the next security release of that release line (either weekly or LTS).

Here is an attempt at an example using LTS releases from 2024:

Jenkins LTS 2.426.3 was released 24 Jan 2024 and included important security fixes. That ended the life of all preceding Jenkins LTS releases because the security fix was only available in 2.426.3, not in any older release. Users that chose to not upgrade to Jenkins 2.426.3 were choosing to run with with known security vulnerabilities.

Jenkins LTS 2.440.1 was released 4 weeks later, 21 Feb 2024 and included important security fixes. That ended the life of all preceding Jenkins LTS releases because the security fix was only available in 2.440.1, not in any older release. Users that chose to not upgrade to Jenkins 2.440.1 were choosing to run with known security vulnerabilities.

Jenkins LTS 2.440.2 was released 4 weeks later, 20 Mar 2024 and included important security fixes. That ended the life of all preceding Jenkins LTS releases because the security fix was only available in 2.440.2, not in any older release. Users that chose to not upgrade to Jenkins 2.440.2 were choosing to run with known security vulnerabilities.

Jenkins LTS 2.440.3 was released 4 weeks later, 17 Apr 2024 and included important security fixes. That ended the life of all preceding Jenkins LTS releases because the security fix was only available in 2.440.3, not in any older release. Users that chose to not upgrade to Jenkins 2.440.3 were choosing to run with known security vulnerabilities.

Jenkins LTS 2.452.1 released 4 weeks later 15 May 2024 and did not include any security fix. In one sense, Jenkins 2.440.3 could be considered end-of-life with the release of Jenkins 2.452.1. However, because it did not include a security fix, there might be an argument that 2.440.3 was not yet end-of-life.

Jenkins LTS 2.452.2 released 4 weeks later 12 Jun 2024 and did not include any security fix. In one sense, Jenkins 2.452.1 could be considered end-of-life with the release of Jenkins 2.452.2. However, because it did not include a security fix, there might be an argument that 2.440.3 and 2.452.1 were not yet end-of-life.

Jenkins LTS 2.452.3 released 4 weeks later (10 Jul 2024) and did not include any security fix. In one sense, Jenkins 2.452.2 could be considered end-of-life with the release of Jenkins 2.452.3. However, because it did not include a security fix, there might be an argument that 2.440.3, 2.452.1, and 2.452.2 were not yet end-of-life.

Jenkins LTS 2.452.4 and Jenkins LTS 2.462.1 released 4 weeks later (7 Aug 2024) with important security fixes. That ended the life of all preceding Jenkins LTS releases because the security fix was only available in 2.452.4, not in any older release. Users that chose to not upgrade to Jenkins 2.452.4 or 2.462.1 were choosing to run with known security vulnerabilities.

This way of thinking about end-of-life is not as simple to describe. A release reaches end-of-life when the next security release is available.

Hi Mark,

Thank you for your response. We’ve been consistently upgrading to the latest LTS version of Jenkins each time a new version is released. This approach has allowed us to stay in compliance with security patches and maintain the stability of our systems.

Thanks again,
Surya