Qubes OS 4.0 is scheduled to reach end-of-life (EOL) on 2022-08-04 — one month from the date of this announcement.

What about patch releases?

The Qubes OS Project uses the semantic versioning standard. Version numbers are written as <major>.<minor>.<patch>. When a major or minor release reaches EOL, all of its patch releases also reach EOL. For example, in this case, when we say that “Qubes 4.0” (without specifying a <patch> number) is approaching EOL, we’re specifying a particular minor release, inclusive of all patch releases within it. This means that Qubes 4.0.0, 4.0.1, 4.0.2, 4.0.3, and 4.0.4 will all reach EOL at the same time (on 2022-08-04), since they are all just patch releases of the same minor release.

How are EOL dates determined?

According to our support policy, stable Qubes OS releases are supported for six months after each subsequent major or minor release. This means that Qubes 4.0 reaches EOL six months after Qubes 4.1 was released. Since Qubes 4.1.0 was released on 2022-02-04, Qubes 4.0’s EOL date is six months later, on 2022-08-04.

Fun fact: Qubes 4.0.0 was initially released on 2018-03-28, which means that it will be four years, four months, and one week old when it reaches EOL. That’s the longest support period for a stable Qubes release in our project’s history!

What should I do?

First off, if you’re already using Qubes 4.1, then you don’t have to do anything. This announcement doesn’t affect you.

However, if you’ve stood by the venerable Qubes 4.0 till now, then you’ll want to make sure you upgrade to Qubes 4.1 by 2022-08-04. When you upgrade, though, depends on a few factors. You have several options (in no particular order):

Allow me to explain what I mean by the last option: While we certainly hope to be able to announce the stable 4.1.1 release within the next few weeks, we cannot guarantee that outcome. After all, the entire point of having release candidates is because sometimes major bugs are discovered in builds that were thought to be nearly ready for release. While we don’t expect any, we can never be certain that no such bug will be found.

So, for those looking for a clean installation option, the main advantage of the existing 4.1.0 ISO is that it is already available right now, while there’s a decent chance but no guarantee that the stable 4.1.1 ISO will be ready in time. Meanwhile, the release candidate is intended for testers and adventurous types who don’t mind a bit of risk. The release candidates are not intended for cases in which system reliability is required for important work.

The main disadvantage of the existing 4.1.0 ISO is that it’s quite old by now. It’s missing some security updates (which you should download immediately after installing, if you choose to go that route) and comes with an old Fedora template that has already reached EOL (which you should upgrade immediately after installing or refrain from using in favor of other templates).

If you’re not in any particular hurry to upgrade (and, if you’ve been content to stick with 4.0 until now, then you’re probably not), one strategy is simply to wait until closer to the EOL date, and see whether the stable 4.1.1 ISO arrives in time. If it does, great! You can preform a clean install using that. If it doesn’t, then you haven’t lost anything. You still have the same choices you have right now. Just make sure you to leave yourself enough time to upgrade one way or another!