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 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 | X chosen | Y chosen | Z chosen |
The cycle starts with picking an LTS baseline at week 0. Then, 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.
The baseline release is typically between 2-5 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 a bug fix be backported to LTS by labeling with lts-candidate. 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 instance can be migrated.
Make sure that the weekly release you’re migrating to has been released after the LTS version you’re migrating from.
While almost always any weekly more recent than the LTS baseline release will be compatible, important fixes that are in the LTS release, such as security fixes, may not be present in older weekly releases.
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.
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.