<p>A rolling release is newer, with cutting-edge functionality, but potentially more defects. LTS is more stable. If stability is your priority (as it generally is for DevOps), LTS would be the release to use.</p>

<p><strong>Note</strong>: Deploying your own code often is unrelated to choosing between a bleeding edge or LTS release of a third party product. You want your external dependencies to be as stable as possible to mitigate risk so that you are more free to do more frequent releases of your own product.</p>

CC BY-SA 3.0
2017-03-05T00:23:13.120Z
I'm downvoting because I don't believe stability is the priority of DevOps. A more balanced priority may read: increasing developer agility while maintaining an availability target. Prioritizing stability incentivizes fewer changes, which contradicts the oft-cited "deploy-often and fail-fast" pursuit of DevOps.
Woodland
CC BY-SA 3.0
2017-03-05T01:13:59.750Z
@WoodlandHunter I am sorry but i completely disagree; without any confidence, which you get from stability/reproducibility, you not only de-incentivice change, you make it risky. Btw, while this community accepts opinionated contributions, I am not sure downvoting on an opinion base would be ok.
ᴳᵁᴵᴰᴼ
CC BY-SA 3.0
2017-03-05T04:00:19.637Z
Deploying your own code often is unrelated to choosing between a bleeding edge or LTS release of a third party product. You want your external dependencies to be as stable as possible to mitigate risk so that you are more free to do more frequent releases of your own product.
Adrian
CC BY-SA 3.0
2017-03-05T04:31:43.413Z
I agree with that, Adrian. "Stability is the priority of DevOps" is what I argued against.
Woodland
CC BY-SA 3.0
2017-03-05T14:11:21.370Z
Reliability is a huge part of DevOps, and I believe stability for systems and avoiding failure is a large part in that. The meaning of "stability" in terms of LTS actually means "avoiding change", which is not exactly the kind of stability you necessary want to have, but this answer is still relevant imho.
Evgeny Zislis
CC BY-SA 3.0
2017-03-04T19:27:52.863Z
2017-03-08T06:56:08.563Z
2017-03-08T06:56:08.563Z
Adrian
<p>I don't think there's a good answer that applies to all software packages or situations. </p>

<p>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.</p>

<p>Some things to consider before going with a rolling release package:</p>

<ul>
<li>Who are the primary users of the package, and in what environment?</li>
<li>What is your tolerance for risk?</li>
<li>What is your process for performing upgrades?</li>
</ul>

<p>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.</p>

<p>My recommendation is that servers (with the exception of sandbox/R&amp;D machines) should use LTS releases. On desktop machines it depends on the end user and what that individual wants.</p>

<p>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.</p>

<p><strong>Note</strong>:</p>

<p>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.</p>

CC BY-SA 3.0
2017-03-04T19:46:57.400Z
2017-03-04T20:07:14.043Z
2017-03-04T20:07:14.043Z
bradym
<p>There are software packages that offer a choice between either of those types of releases:</p>

<ul>
<li>a <strong><em>Rolling</em></strong> release.</li>
<li>a <strong><em>Long Term Support</em></strong> (= LTS) release.</li>
</ul>

<p>Consider the <a href="http://releases.ubuntu.com/" rel="noreferrer">available Ubuntu releases</a> as an example of this. And imagine that:</p>

<ul>
<li>some software requires a Linux server,</li>
<li>whereas the decision is made (for whatever reason) to go for Ubuntu,</li>
<li>the decision makers do know what these release types actually mean,</li>
<li>it turns out that any release starting from 16.04 and above will do,</li>
<li>but whatever release is selected, all Dev / QA / Operational servers must run the very same release.</li>
</ul>

<p><strong>Question</strong>: </p>

<p>What are the <strong><em>criteria</em></strong> one should use to decide about which type of release to select?</p>

<release>
How to decide between Rolling Releases versus LTS Releases?
Pierre.Vriens
# How to decide between Rolling Releases versus LTS Releases?

(Asked by: username_0 on 2017-03-04)

There are software packages that offer a choice between either of those types of releases:

* a ***Rolling*** release.
* a ***Long Term Support*** (= LTS) release.

Consider the [available Ubuntu releases](http://releases.ubuntu.com/) 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?

**Tags:** release


---

## 2 answers

### Answer by username_5 on 2017-03-04. Score: 6 | Accepted answer

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:

* 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.


---

### Answer by username_1 on 2017-03-04. Score: 1

A rolling release is newer, with cutting-edge functionality, but potentially more defects. LTS is more stable. If stability is your priority (as it generally is for DevOps), LTS would be the release to use.

**Note**: Deploying your own code often is unrelated to choosing between a bleeding edge or LTS release of a third party product. You want your external dependencies to be as stable as possible to mitigate risk so that you are more free to do more frequent releases of your own product.

> **Comments:**
> **username_2**: I'm downvoting because I don't believe stability is the priority of DevOps. A more balanced priority may read: increasing developer agility while maintaining an availability target. Prioritizing stability incentivizes fewer changes, which contradicts the oft-cited "deploy-often and fail-fast" pursuit of DevOps.  
> **username_3**: @username_2Hunter I am sorry but i completely disagree; without any confidence, which you get from stability/reproducibility, you not only de-incentivice change, you make it risky. Btw, while this community accepts opinionated contributions, I am not sure downvoting on an opinion base would be ok.  
> **username_1**: Deploying your own code often is unrelated to choosing between a bleeding edge or LTS release of a third party product. You want your external dependencies to be as stable as possible to mitigate risk so that you are more free to do more frequent releases of your own product.  
> **username_2**: I agree with that, username_1. "Stability is the priority of DevOps" is what I argued against.  
> **username_4**: Reliability is a huge part of DevOps, and I believe stability for systems and avoiding failure is a large part in that. The meaning of "stability" in terms of LTS actually means "avoiding change", which is not exactly the kind of stability you necessary want to have, but this answer is still relevant imho.  

---

