Last checked and updated on 03 May 2026
How Does Jenkins Handle LTS and Regular Version Support?
Jenkins maintains two parallel release lines with fundamentally different support models: a Weekly release line for users who want the latest features fast, and a Long-Term Support (LTS) line for teams that prioritize stability over novelty. Understanding which line you're on determines what kind of fixes you'll receive -- and for how long.
The LTS model follows a 12-week cycle. Every 12 weeks, the community selects a recent Weekly release as a new LTS baseline. That baseline then receives up to three patch releases (X.1, X.2, X.3) spaced four weeks apart. Only backported, battle-tested bug fixes and security patches are allowed into these branches -- no new features.
Once X.3 ships, that LTS baseline is considered complete. The community immediately begins a new 12-week cycle with the next baseline. There is no long multi-year support window per baseline -- each LTS baseline is actively maintained only until its X.3 patch is released, at which point the next LTS baseline takes over.
| Release Line | Cadence | What Gets In | Who Should Use It |
|---|---|---|---|
| Weekly | Every week | New features + bug fixes | Plugin developers, early adopters |
| LTS | Every ~4 weeks (patch), new baseline every 12 weeks | Backported bug fixes + security patches only | Production CI/CD teams that need stability |
End-of-life dates for each LTS baseline are not published as fixed calendar dates. A baseline effectively reaches end of life when its X.3 patch is released and the community moves on to the next baseline. Check the release table above to identify which baselines are still receiving patch updates versus which have already shipped their final X.3 release. For the official LTS policy, see the Jenkins LTS Release Line documentation.
What Can Go Wrong When You Stay on an Outdated Jenkins Baseline?
The biggest risk with running an outdated Jenkins baseline is plugin incompatibility. The Jenkins ecosystem moves fast -- core API changes accumulate quickly in Weekly releases, and plugin authors tend to target recent LTS baselines. Once your baseline is two or three cycles behind, you will start seeing plugins that refuse to install or update because they require a newer Jenkins core version.
Security exposure is the second concern. Jenkins security advisories are issued regularly by the Jenkins Security Team. Fixes are backported to the current active LTS baseline -- but not to older ones. If your baseline has already shipped its X.3 patch, you will not receive security fixes through the normal update mechanism.
In practice, the failure mode looks like this: you try to update a plugin, Jenkins reports a core version conflict, you skip the update, the plugin accumulates unpatched CVEs, and your pipeline tooling quietly drifts out of a maintainable state. Most teams don't notice until something breaks in production.
| Risk Area | What Happens in Practice |
|---|---|
| Plugin updates blocked | Plugins targeting newer LTS baselines refuse to install |
| Security patches unavailable | CVE fixes are not backported to completed baselines |
| Pipeline breakage | Community-maintained pipeline steps deprecate older API signatures |
| No community support | Bug reports on old baselines are typically closed as "please upgrade first" |
What Actually Happens After a Jenkins LTS Baseline Ships Its Final Patch?
When a Jenkins LTS baseline ships its X.3 patch, the Jenkins project moves all active development to the next LTS cycle. The completed baseline does not enter a "security-only" grace period -- there is no Phase 2 with minimal fixes. It simply stops receiving any updates.
Practically, the Jenkins project does not maintain a published EOL date per baseline in the way that Linux distributions do. The release table above is your best reference: if a baseline already has an X.3 release and the community has moved on, that baseline is done. You can continue running it, but you are on your own.
What the community does maintain is a clear upgrade path. Because Jenkins stores data in a forward-compatible format, upgrading from one LTS baseline to the next is generally straightforward -- as long as you are moving to a newer baseline, not a lower version number. Downgrading is not supported and can corrupt your Jenkins home directory.
Plugin compatibility is what makes staying current a real-world priority rather than a theoretical one. When your baseline falls more than one or two cycles behind the current active LTS, the gap in plugin API expectations widens, and routine plugin maintenance turns into a migration project.
How Do You Check Which Jenkins Version You Are Running?
There are several ways to check your Jenkins version depending on how you access your instance.
From the Jenkins UI
Log in and look at the bottom-right corner of any Jenkins page. The version number is displayed in the footer alongside the Jenkins logo.
From the CLI or SSH
If you have the Jenkins CLI jar available:
java -jar jenkins-cli.jar -s http://your-jenkins-url/ versionVia the REST API
Jenkins exposes its version in the HTTP response header of any API call:
curl -s -I http://your-jenkins-url/api/json | grep -i X-JenkinsThe X-Jenkins header contains the version string, for example X-Jenkins: 2.452.3. The format MAJOR.BASELINE.PATCH tells you which LTS baseline you are on (the middle number) and which patch release within that baseline (the last number).
Reading the version format
| Version Segment | Meaning | Example |
|---|---|---|
| First number | Jenkins major version (always 2 currently) | 2 |
| Second number | LTS baseline (or Weekly build number) | 452 |
| Third number | Patch release within LTS baseline (absent in Weekly) | 3 |
If your version string has only two segments (e.g. 2.460), you are on the Weekly release line. Three segments means LTS. Cross-reference the second segment against the release table above to determine whether your baseline is still active.
FAQ
Q1: How often should I upgrade Jenkins LTS in production?
Most teams find that upgrading every one or two LTS cycles -- roughly every 12 to 24 weeks -- keeps plugin compatibility manageable without introducing change too frequently. Waiting longer than two full cycles tends to turn upgrades into multi-step migrations rather than routine maintenance. The release table above shows which LTS baselines are currently active and which have shipped their final patch.
Q2: Is the Jenkins Weekly release line suitable for production use?
It depends on your team's tolerance for change. The Weekly line is fully functional and used in production by many teams, particularly those with plugin developers or early adopters who need the latest API surface. The LTS line exists specifically for teams that want fewer surprises. If you don't have a dedicated Jenkins administrator tracking changelogs weekly, the LTS line is the safer default.
Q3: What is the difference between a Jenkins LTS baseline and a patch release?
The baseline is the Weekly release that the community selects as the foundation for a new LTS cycle -- for example, X.1 through X.3 are all patch releases of baseline X. Patch releases contain only backported bug fixes and security patches. The baseline itself is identical to the Weekly release it was cut from. When people say "which LTS are you on," they typically mean the baseline number (the middle segment in the version string).
Q4: Can I run Jenkins plugins on an older LTS baseline indefinitely?
You can run them, but you cannot update them indefinitely. Plugin authors set minimum core version requirements in their metadata. Once the minimum required version exceeds your installed baseline, the Plugin Manager will block the update. Over time this means you are locked into progressively older plugin versions, which may themselves have unpatched issues. The practical ceiling varies by plugin, but falls quickly once your baseline is more than two cycles behind the current active LTS.
Q5: Does Jenkins provide security patches for older LTS baselines after the X.3 release ships?
No. The Jenkins Security Team issues fixes as part of the current active LTS cycle. Once a baseline has completed its X.3 patch and a new cycle has started, the old baseline receives no further security updates through official channels. Security advisories will note which versions are affected, and the fix will be available only in the current active LTS and recent Weekly releases. Running a completed baseline means applying any security patches yourself or accepting the exposure.