6

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 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?

  • I'm not entirely sure this is on-topic, because while it's relevant to DevOps, the connection isn't made in the question (there's no context). As written this would be a question for something like SuperUser. – Adrian Mar 4 '17 at 19:29
  • 1
    @Adrian see my updated question, enough "context" now you think? – Pierre.Vriens Mar 4 '17 at 19:45
  • 1
    This seems on topic to me. – wogsland Mar 6 '17 at 2:51
5

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.

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.

  • 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 Hunter Mar 5 '17 at 0:23
  • @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. – ᴳᵁᴵᴰᴼ Mar 5 '17 at 1:13
  • 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 Mar 5 '17 at 4:00
  • I agree with that, Adrian. "Stability is the priority of DevOps" is what I argued against. – Woodland Hunter Mar 5 '17 at 4:31
  • 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 Mar 5 '17 at 14:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.