LTS Release Line

Skip to end of metadata
Go to start of metadata

What is this?

Jenkins produces a new release weekly to 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 for important bug fixes, even if such a release line lags behind in terms of features.

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.

How do I get it?

On the homepage, select the "Long-Term Support Release" tab on the right.
Here you will see the usual Jenkins download options: a .war file, or platform-specific packages.

Once you have downloaded an LTS release, proceed with installation as normal.

If you had a Latest&Greatest release running before and now have switched to LTS, you should open Manage Jenkins->Manage Plugins->Advanced and press "Check now".
This way you ensure to get the proper update notifications for LTS and LTS-compatible plugins instead of Latest&Greatest. After you do this you may need to remove the contents of ${JENKINS_HOME}/updates to ensure that Jenkins shows the correct updates for the LTS stream.

Check the LTS Changelog to see what's in the latest LTS release.

What will be in next LTS?

See the list of issues pending backporting. In case there is a pressing issue not listed, feel free to add "lts-candidate" label to the issue so it will be considered for backporting.


  • 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 1.X.
  • When we pick the next 1.X as the baseline, 1.Y.* releases will cease.
  • We'll create a branch from 1.X to produce stable but older patch releases of 1.X.1, 1.X.2 and 1.X.3
  • Changes to this branch will be restricted to backported cherry-picked changes 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.
  • Release candidate is published two weeks before a minor release.

Following table demonstrates release dates within the 12 week cycle. The cycle starts 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 1.X.1. Backporting and rc testing is repeated two more times producing 1.X.2 and 1.X.3. This concludes cycle for a given baseline and the new one is started immediately.

Week 2 4
Release 1.X.1-rc

See the event calendar.

We aim for no API change in LTS releases and we are backporting important fixes first. LTS release line gets its update center feed that only advertises LTS updates and not the main release line. It also gets the limited subset of plugins that work with the LTS release line. This process is adjusted as we go. Please let us know your feedback.

Backporting process

  • Users can propose that an issue to be backported to LTS by labeling with lts-candidate
  • Backporters search for this label to list up issues that need to be attended
  • 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, and so on.
  • If backported, a label like 1.480.4-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 1.480.4-rejected is used to tell the proposer that this ticket will not be backported

See Backporting toolkit for LTS for the tooling available for the developers.

Call for help/action

  • Several companies that I know of maintain their own private branches off of Jenkins for stabilization and internal customizations. We'd like those folks to shift a part of the effort to this release line. It has benefits to them as well, because we'd have a larger number of aggregated eyeballs on the same branch.
  • We need volunteers to backport fixes from the mainline release.
  • Once the backporting has been done, you can help by downloading and testing the LTS Release Candidate.
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Add Comment