All the Facts about Linux Long-Term Support Releases
Long Term Support (LTS) releases are as old as software. However, Canonical, the company behind Ubuntu, was the first to use the term, and now other open source projects, including the Linux kernel and many distributions, distinguish between LTS, regular, and rolling releases, each of which has different advantages and appeal to a different class of user.
Many users are content with regular releases every six to 18 months. Others who demand the very latest, prefer rolling releases, in which each package is updated whenever it is ready. By contrast, as the term implies, LTS releases are supported longer periods — typically, two to five years, although Canonical also offers Extended Security Maintenance as a paid service for another two years.
LTS releases are supported through their specified support duration by security updates, bug fixes, backports, and new device drivers, just like a regular release, although in some projects like Debian, they do not have point releases, which means that how and when fixes are applied can be different than in a regular release. Similarly, LTS releases may support only the most popular hardware architectures supported by regular releases.
LTS releases are especially suited to commercial products, whose own life cycles are often even shorter. Roberto C. Sánchez, who works on Debian LTS releases, gives other scenarios when LTS releases might be desirable: “there may be a need to continue using older versions of key software packages in order to allow time for porting of mission critical systems which depend upon older underlying components. Or the number and scale of systems to upgrade in a particular environment may be so large as to require additional time to plan and completely deploy an update as a large as moving from one Debian release to the next.”
In addition, LTS releases are often the basis of distributions derived from Ubuntu such as Trisquel GNU/Linux because they make the amount of maintenance manageable a small group of contributors. Clément Lefèbvre of Linux Mint says, “By moving to LTS, I think we made Linux Mint more stable as an operating system, and it allowed us to produce better quality and to focus more on development than before. I’m not sure we could be as ambitious or demanding on the development side of things if we hadn’t made that choice.”
In the case of Debian, the long intervals between releases and support for old releases for a year after they are replaced might make LTS releases seem redundant. Yet the interests of sponsors led to Debian LTS for practical reasons. Looking at the list of Debian LTS sponsors, Raphaël Hertzog notes that “at least three of them use Debian in an embedded context and doing major upgrades on such devices is really costly, while providing backward-compatible security updates is not a problem. Others are hosters and they want security updates available for their users who don’t want to do major updates on their working servers.”
Not all projects include LTS support. OpenSUSE maintains a regular and a rolling release, while Fedora’s need for an LTS release is filled by Red Hat Enterprise Linux and CentOS being derived from it. Even so, Fedora Leader Matthew Miller notes that some users ask for a release that is both LTS and rolling, even though the two strategies are opposites.
In fact, if you are not an LTS user yourself, you might be surprised by how many use these releases. According to Dustin Kirkland, Canonical’s Head of Ubuntu Product and Strategy, 94 percent of all Ubuntu desktop and servers use LTS releases. Similarly, Greg Kroah-Hartman, who maintains LTS Linux kernels, points out that they are used on what must be millions of Android devices. Elsewhere, the number of users is lower and drops even lower as a release reaches its end of life cycle, yet Debian developer Raphaël Hertzog estimates that at least 25 percent of users stay a Debian LTS release until its very end.
The Costs of LTS
The life cycles of LTS releases is only loosely in sync with those of regular releases. Just as importantly, the priorities are different. As Kirkland points out, “During the course of building an Ubuntu LTS release, we shift our focus on to higher quality, extra testing, stable versions. We are slightly less aggressive in developing and integrating new features, to the benefit of extra stability and quality.”
Such differences in priorities can lead to different technical decisions, as well as different working relationships.
For example, in a regular release, a bug-fix may be simply added to the next point release or even the next general release. However, since LTS releases generally do not have point releases, LTS maintainers have to decide whether to issue a fix or to include it as a security fix or backport. Similarly, an upstream package for a current release cannot be assumed to work in an LTS release. Such questions and how they are resolved require coordination between the mainstream and LTS maintainers.
For a small or well-focused project, these extra considerations may be easily manageable, requiring no more than a quick education in the different priorities. In the case of the Linux kernel, Kroah-Hartman says, that the extra effort may be no more than a developer willing to maintain the LTS release, and developers interested in contributing packages or testing the result.
In these cases, LTS support may only a part-time concern among a maintainer’s routine. However, in larger projects, LTS can become more of a specialty. Debian LTS, for example, currently has 18 some time contributors, and is looking for sponsorship for a full-time position. In the same way, Kirkland reports that “we have many dedicated engineers at Canonical who maintain the Ubuntu LTS releases — kernel, user space, bug fixers, and security fixes. We also have a dedicated support team with whom Canonical’s commercial customers engage.”
A particular concern for LTS releases is security fixes. Kirkland singles out several areas of concern that are also mentioned by other LTS developers:
- Security vulnerabilities are typically fixed upstream against head or trunk. It’s the responsibility of the distribution to backport those fixes to older supported versions of that software.
- As software ages, the drift between the older released version and head/trunk increases. This makes it riskier, and more difficult to backport fixes and test the results.
- Eventually, the software goes end-of-life and the distribution stops publishing security updates. These dates are clearly and publicly communicated many times.
When an LTS Linux kernel is no longer maintained, users are expected to upgrade for themselves, just as they would for any other kernel. However, in other projects, the upgrade can be as elaborate as for a general release, with shims to ease the transition, especially when a major shift in technology such as the shift to systemd is involved. Once the transition is made, the cycle begins anew.
Pros and Cons
Some features of LTS releases are ambiguous. As Sánchez points out, some might regard the fact that obsolete standards may linger in LTS as a fault, others that the continuation of older standards means that LTS releases extend some sort of official support for software that is going to be used anyway.
However, generally, the disadvantages and advantages of LTS releases are straightforward. On the one hand, “The cons are obvious,” Lefèbvre says. “At the end of an LTS cycle, you’re basically years away from what’s considered new.”
On the other hand, Lefèbvre says, “The non-LTS cycle is too fast. With a new package base every six months we’re constantly chasing bugs, fixing new regressions, adapting software to library changes and basically producing a huge amount of work simply to maintain the same level of quality with very little time left to actually improve things. By moving to LTS we focus on the same development platform, the same target, the same package base for a whole two years and so after we adapt to it, we’ve got a significant amount of time to invest into developing new features and improving aspects of the OS which are important to the users.
Some might consider LTS releases may become obsolete with the continued rise of technologies such as containers and universal packages. Yet, as Hertzog says, “The demand for LTS is not going away. It might even be fostered. The desire to run old software that is only tested in a specific old environment is not going away. We can hide it a bit in a container, but the old base system must still be kept secure.” From this perspective, LTS releases seem likely to remain a major niche in software development for some years to come.
Feature image via Pixabay.
