The weekly Jenkins releases deliver bug fixes and new features rapidly to users and plugin developers who need them. But for more conservative users, it’s preferable to stick to a release line which changes less often and only receives important bug and security related fixes, even if such a release line lags behind in terms of features. Several companies maintain their own private branches off of Jenkins for stabilization and internal customizations. We encourage everybody to shift a part of the effort to this release line.
This is called the Jenkins Long-Term Support release, or LTS. The concept is very similar to the LTS concepts in Ubuntu and our model is described below.
Every 12 weeks, the community will pick one of the relatively recent releases by consensus and mark it as the baseline for the next "stable but older" release line. Let’s say this was version X. We’ll create a branch from X to produce stable but older patch releases of X.1, X.2, and X.3. Changes to this branch will be restricted to backported cherry-picked bug fixes from the trunk that are "battle-tested" — meaning those commits that have already been a part of a main line release for more than a week. There are 3 minor releases for a baseline published in four week cycles. A release candidate is published two weeks before a minor release.
The following table demonstrates release dates within the 12 week cycle:
| Week | 0 | 2 | 4 | 6 | 8 | 10 | 12 | 14 | 16 | 18 | 20 | 22 | 24 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Release | W.3 | X.1 RC | X.1 | X.2 RC | X.2 | X.3 RC | X.3 | Y.1 RC | Y.1 | Y.2 RC | Y.2 | Y.3 RC | Y.3 |
| Baseline Selection | Y chosen | Z chosen |
There is a two week period for backporting followed by two weeks for testing the release candidate resulting in the release of X.1. Backporting and RC testing is repeated twice, producing X.2 and X.3. This concludes the cycle for a given baseline and the new one is started immediately based on the new baseline selected in week 10.
The baseline release is typically between 0-3 weeks old when it is chosen, so X.1 LTS releases are published about 6-9 weeks after their baseline.
See the event calendar for the specific LTS RC/release dates in the near future.
Any user can propose that an issue is backported to LTS by labeling with lts-candidate. For an issue to be eligible for backporting it should be a small, safe-looking, uncontroversial fix for an important bug with no change to API surface. Backporting candidates should be delivered in a weekly release before shipping in an LTS release. Additionally library updates can also be considered if the library contains a public CVE that does not affect Jenkins (if Jenkins is vulnerable via a library then the security process applies). Backporters use this query to list up issues that need to be attended once resolved.
Aside from the model set out above, backporters apply some subjective selection — for example whether a fix is easy and safe to backport, confidence in the fix, importance/impact of the problem, how much time is left until the end of backporting window and so on.
If backported, a label like 2.46.2-fixed is applied to communicate to the user what LTS version(s) it’s going to be in.
If the backport is rejected, a label like 2.46.2-rejected is used to indicate that this ticket will not be backported to that specific release — but it may still be picked up in a later LTS release.
Due to how Jenkins stores data internally, users are generally able to upgrade to newer releases, but not downgrade to older releases. In the context of LTS, the baseline is almost always the deciding factor that determines to which releases of the other line a Jenkins controller can be migrated.
Make sure that the weekly release you’re migrating to has been released after the LTS version you’re migrating from.
We recommend that users moving from LTS to weekly should use the most recent weekly release to assure they have the latest features and fixes.
Make sure that the LTS baseline you’re migrating to is more recent (compared numerically) than the weekly release you’re migrating from. For example, if you’re using Jenkins 2.5, 2.18, or 2.46, you will be able to upgrade to Jenkins LTS 2.46.x without major problems. However, if you’re using Jenkins 2.47 or Jenkins 2.56, you may have problems downgrading to Jenkins LTS 2.46.x, even if the specific LTS releases were created at a later date than the weekly release you’re using.
The Jenkins project operates multiple update sites that inform Jenkins about available updates to Jenkins and plugins. As Jenkins sends its current version when requesting new data, the same URL can be used for all releases of Jenkins, and will always serve the most appropriate update information. For example, instances running an LTS release of Jenkins will only be offered LTS versions of Jenkins to upgrade to. See updates.jenkins.io to learn more.
After switching between release lines, it’s recommend to update the update site metadata cached in Jenkins by hitting the "Check now" button in the Plugins Manager (further instructions here). Otherwise, Jenkins may offer to update or install plugins whose newer versions are incompatible with the installed version.