You probably don’t need an LTS release
One topic that often takes up more brain space than it needs is the concept of a long-term support (LTS) release. An LTS is what the name implies: a release with a longer support period than the usual for a project. LTS releases can be a benefit to users. To some, having an LTS release may signify that this is a Real, Serious Project™. But most projects don’t need one.
Why you don’t need one
The most obvious downside to an LTS release is that it imposes a significant burden on the project maintainers. The longer the definition of “LT”, the greater the burden. I suspect the function is closer to a power function than a linear one. Backporting fixes takes a lot of effort and the effort required compounds the further away a fix is from the original state of the software. If you don’t have people with the time, skills, and motivation to maintain an LTS release, it will not go well.
LTS releases are also often in tension with what users want. Some project maintainers admit their LTS patches are poorly tested, which means the LTS release may end up being buggier. That’s not ideal. People say they want an LTS release but then they get upset if they don’t get access to the new features, too. What they usually want is an easy upgrades with no regressions. The time not spent backporting fixes can be better spent improving test suites and upgrade paths.
When an LTS release makes sense
That’s not to say that an LTS is never a good idea. The more of the following that are true, the more sense it makes for your project to have one:
- Upgrades between versions are difficult and cannot easily be improved
- You have a large user base in production use
- Project contributors have the skill, time, and interests to maintain the release
- Someone is willing to pay good money for it
- The project is very large and complex (e.g. a kernel, operating system, or desktop environment)
- The project is a foundation that other projects are built upon (e.g. a language or framework)
You’ll note that the list above does not say “other projects do” or “users say they want it.” Often, better testing or a longer development schedule addresses the supposed need sufficiently.
This post’s featured photo by Joshua Olsen on Unsplash.