Ubuntu, Fedora, OpenSUSE - how different release cycles can impact enterprise server space?

Krystian Kacprzak
System Administrator

It’s spring again, and every Linux fan knows what it means - new releases. During Linux App Summit in Brno, we witnessed a joint release party by Fedora Project and Canonical, both celebrating the release of new versions of their respective distributions - Fedora 38 and Ubuntu 23.04 STS. We're also looking forward to the upcoming OpenSUSE 15.5 in June. Events like this, especially the half-Fedora half-Ubuntu cake, show that despite being fierce competitors, both teams can still cheer for each other and support the work of others.

As for details, Fedora 38 was released on April 17, and Ubuntu on April 20, giving users new kernel 6.2, GNOME 44, drivers for the absolute latest hardware, like AMD Ryzen 7th gen processors and better support for Intel 13th gen, along with better support for ARM processors and first, cautious tries at supporting Apple M-series processors.

But what’s all this fuss about? Can’t Linux be “just updated”? What are these “releases”, why are they numbered the way they are, and how different companies approach their release cycles? I think this is great opportunity to talk about this and give some insight into how Linux distributions are updated.

Why should you care about release cycles?

A release cycle is the process by which a new version of the Linux operating system is developed, tested, and released to the public. It defines how the development team plans new major versions and their delivery frequency- every month, once a year, or every 5 years with nothing in between? Or maybe small incremental updates every once in a while? Or push new features to users as soon as they are developed, without waiting for a strict release window? 

Interestingly, three major competitors in enterprise server space - Canonical, Red Hat/Fedora and SUSE/OpenSUSE each take vastly different approaches to this topic. Let’s take a closer look.

Release cycle philosophies

In short, the most popular release cycle philosophies are LTS Point-Release, Semi-Rolling Release and Rolling-Release

Ubuntu is a flagship example of an LTS Point-Release scheme.

That’s why every 2 years, Ubuntu releases its LTS, or Long Time Support version targeted at enterprise production environments. These releases are fully supported for the 2 years until the next LTS release and then receive 3 years of security-only support. On top of that, users can extend support up to 10 years total. There is a catch, however - during that time, they don’t receive major kernel updates (using LTS kernel) or feature updates, and very few software updates get backported from newer releases to LTS. This results in a very stable OS that doesn’t change but can pose major problems when upgrading to the next release, especially if you skip some releases.

As an aside, Ubuntu also offers (Short Time Support) releases every six months. These are purely enthusiast-focused desktop releases, and should not be used in production servers due to their extremely short lifespan and support.

Fedora , on the other hand, places their focus on Semi-Rolling Releases, providing new versions roughly every 6 months. 

Due to the extensive QA required by RedHat, and the sheer amount of contributors, it often results in delayed releases (like Fedora 37, which was delayed for almost 2 months). Each release is supported for about 13 months. In reality, each N version is supported until the release of the N+2 version plus 1 month. So with the latest release of the F38 timer started for the last month of support for F36.

On top of that, every release is extensively supported and updated until the next version, resulting in major releases not being so major (there's literally one version difference between GNOME in Fedora 37 and Fedora 38, whereas Ubuntu 22.10 and 23.04 are 5 versions apart, despite being also spaced 6 months apart). Since two versions are supported at the same time, and changes are not gigantic (like in the LTS release), it is completely safe for the end-user to wait for a few months or even skip a release, as well as to upgrade as soon as possible every 6 months.

This result is still a very stable but up-to-date OS that has all the benefits of LTS - long support and clear, predictable upgrade date. This approach allows users to benefit from all the bells and whistles available in the newest software versions, like kernels and containerisation, which makes it perfect for software developers focusing on using cutting-edge technologies.

OpenSUSE is a great example of Rolling-Release, but also a bit confusing example of both LTS Point-Release and Semi-Rolling Release. 

Why is that? Well, OpenSUSE has two editions - Tumbleweed and Leap. The former is purely Rolling-Release edition, which has no defined release number, like Ubuntu 22.04 or Fedora 38, instead being updated daily, with all new versions and updates being pushed to repos as soon as they arrive. This results in an absolutely bleeding-edge OS, that is always up-to-date and has the best support for new hardware and software features, but with the downside of being extremely unstable.

Rolling-Release distributions like OpenSUSE Tumbleweed or more enthusiast-focused, like Arch Linux, Debian Sid, are very likely to break with each update, potentially have a lot of bugs and problems, and are in no way suitable for production. 

So why develop Rolling-Release distributions? Well, with all their cons, they are perfect for development environments. You can play around with new versions, and check compatibility before upgrading your main production environment to a specific new version. Having this bleeding-edge sandbox allows you to, for example, check if the container you built on your Ubuntu LTS with Docker 20.10 will still be functional when you upgrade in a year to Docker 23.0, since your Rolling-Release sandbox received this version already.

At the other end of the spectrum to Tumbleweed we have OpenSUSE Leap releases. These strictly follow the 5-year LTS release cycle of SUSE Linux Enterprise (SLE) with their major releases (15.x), but also provide yearly releases (for example, 15.2, 15.4), that are neither LTS nor Semi-Rolling. They have a shorter lifespan than LTS (of about 13 months, just Like Fedora), but they don’t change much -just like LTS releases. Not on that, but SLE uses their own forked and patched kernels, that they release “when they are ready”, so there’s no “cycle” there. However, this has a major upside - OpenSUSE Leap is bug-to-bug compatible with SLE, extremely stable, extremely solid, and can be used as a replacement for both LTS and Semi-Rolling Release distributions.

So what should I use? 

For years, there has been a consensus - LTS releases are best for production. They do not change, they just get security maintenance, and you update them every 6 months. But, well, this doesn't work well right now. Linux has exploded in the last few years, receiving multiple new features and security enhancements. Tools like Docker and Podman are updated constantly, not to mention cloud providers such as OVH, AWS, and GCP using semi-rolling distributions as their bases. 

The web is evolving, the world is evolving, and a 2-year-old or even older OS (like CentOS 7, released in 2014, supported until 2024) just doesn't cut it anymore. Of course, some essential tools are backported to older releases, but for example, Ubuntu 20.04, while still technically supported, is lacking the ability to build Docker images for ARM architecture CPUs (or rather - it is in theory possible, but not as reliable and easy as in newer systems). And that’s a huge problem, if you’re running a company, that focuses intensively on hybrid on-premise plus cloud model, trying to use AWS cloud instances based on ARM CPUs.

That's why more and more projects arise, addressing this issue, like SUSE MicroOS, Fedora CoreOS, and monolithic, semi-rolling distributions designed to be both stable and updated. Even consumer-oriented desktop distributions based on Ubuntu are moving away from its LTS version, switching to yearly releases or straight up abandoning Ubuntu in favour of Debian Sid (for example, VanillaOS 2.0).

There is no silver bullet

As with everything in life, there’s no one perfect choice. Each release cycle philosophy has its uses.

If you are planning on launching a data vault with a lot of storage, and you don’t care about “latest and greatest” features, just want something that works and will not break - something that you don’t even have to remember to upgrade for the next 10 years, then go with LTS. You’ll find nothing better than that! 

But maybe you’re a software developer, and you’re preparing Docker images for multiple architectures, and multiple cloud providers, utilising the newest hardware like Nvidia A-series cards with their Tensor cores to employ machine learning in your project. Then you absolutely need the aforementioned “latest and greatest”, as LTS will simply not have the tools and versions you need. Go with Semi-Rolling then, as this will provide you with all you need, while still being stable, with the downside of having to upgrade from time to time. 

Perhaps you’re a geek (hi 👋), wanting to play around with what Linux have to offer, or you just need a bleeding-edge sandbox, where you can test everything before upgrading your main machine to the new release? If that’s the case, then Rolling-Release should be your choice. 

In short, there’s no silver bullet, and it all boils down to one simple question - what do I need?


We make software better every day

Get in touch

Copyright © 2024 Sonalake Limited, registered in Ireland No. 445927. All rights reserved.Privacy Policy

Nr Cert. 18611 ISO/IEC 27001