snippetMinor
How to decide between Rolling Releases versus LTS Releases?
Viewed 0 times
versusltsrollingbetweendecidehowreleases
Problem
There are software packages that offer a choice between either of those types of releases:
Consider the available Ubuntu releases as an example of this. And imagine that:
Question:
What are the criteria one should use to decide about which type of release to select?
- a Rolling release.
- a Long Term Support (= LTS) release.
Consider the available Ubuntu releases as an example of this. And imagine that:
- some software requires a Linux server,
- whereas the decision is made (for whatever reason) to go for Ubuntu,
- the decision makers do know what these release types actually mean,
- it turns out that any release starting from 16.04 and above will do,
- but whatever release is selected, all Dev / QA / Operational servers must run the very same release.
Question:
What are the criteria one should use to decide about which type of release to select?
Solution
I don't think there's a good answer that applies to all software packages or situations.
Rolling releases are more risky as there is no predictability around when things will change. You may have installed the thing last night and already there's an update to deal with. But what does that update do? Is there enough information to know if you want it? Sometimes, but it depends entirely on the developer/company releasing the package.
Some things to consider before going with a rolling release package:
LTS releases are intended to be used for longer periods of time and often have published lifetimes that enable you to plan and test migrations to the next LTS release well before updates to the package/system end.
My recommendation is that servers (with the exception of sandbox/R&D machines) should use LTS releases. On desktop machines it depends on the end user and what that individual wants.
In fact, I would go so far as to say unless there are specific and very good reasons to go with a rolling release, always use LTS releases.
Note:
When dealing with higher-ups, appealing to their desire not to spend money is always a good tactic. Rolling releases are more expensive in the long run when you consider the amount of time spent by employees testing, installing, dealing with bugs from new versions, etc. While you'll have to do some of this with LTS releases, their longevity means it's significantly less.
Rolling releases are more risky as there is no predictability around when things will change. You may have installed the thing last night and already there's an update to deal with. But what does that update do? Is there enough information to know if you want it? Sometimes, but it depends entirely on the developer/company releasing the package.
Some things to consider before going with a rolling release package:
- Who are the primary users of the package, and in what environment?
- What is your tolerance for risk?
- What is your process for performing upgrades?
LTS releases are intended to be used for longer periods of time and often have published lifetimes that enable you to plan and test migrations to the next LTS release well before updates to the package/system end.
My recommendation is that servers (with the exception of sandbox/R&D machines) should use LTS releases. On desktop machines it depends on the end user and what that individual wants.
In fact, I would go so far as to say unless there are specific and very good reasons to go with a rolling release, always use LTS releases.
Note:
When dealing with higher-ups, appealing to their desire not to spend money is always a good tactic. Rolling releases are more expensive in the long run when you consider the amount of time spent by employees testing, installing, dealing with bugs from new versions, etc. While you'll have to do some of this with LTS releases, their longevity means it's significantly less.
Context
StackExchange DevOps Q#326, answer score: 6
Revisions (0)
No revisions yet.