Ubuntu

## The number is a calendar date Ubuntu's version number encodes when the release came out: two digits of year, a dot, two digits of month. `18.04` is April 2018, `21.10` is October 2021, `24.04` is April 2024. Because the cadence is fixed, only two month values ever appear: `.04` and `.10`. There is no semantic-versioning meaning here, no "major" versus "minor" — the number tells you the age of the release, which is exactly what an operator planning a support window needs to know. If you can read the number, you can compute how much life the machine has left without looking anything up. ## Two kinds of release Every six months Ubuntu publishes an **interim release** (sometimes called a standard release). It is supported for **nine months** — six months until the next one, plus a three-month grace period. Interim releases are where new desktop stacks, newer toolchains and newer kernels land first. They are appropriate for a workstation that wants current software and for testing what the next LTS will contain; they are a poor fit for a server fleet, because nine months means upgrading roughly twice a year forever. Every **two years**, the April release is designated **Long Term Support (LTS)**: 16.04, 18.04, 20.04, 22.04, 24.04. An LTS receives **five years of standard security maintenance** from Canonical at no cost. That is the release almost every production fleet runs. Canonical's paid **Ubuntu Pro** subscription (free for personal use on a limited number of machines) adds Expanded Security Maintenance, which continues patching well past the five-year mark. ## What "supported" actually covers Support is not uniform across the archive. Ubuntu splits packages into four components: **main** and **restricted** are maintained by Canonical; **universe** and **multiverse** are community-maintained. The five-year LTS guarantee is a guarantee about **main** (and restricted); universe packages get best-effort community attention. This matters more than it sounds: a large fraction of what a real server installs lives in universe. Ubuntu Pro's `esm-apps` stream is precisely the product that extends Canonical's coverage to universe. Updates arrive through **pockets** attached to the release: the release pocket itself, `-updates` for bug fixes, `-security` for security fixes, and `-backports` for opt-in newer versions. Security patching an LTS means backporting the fix into the version the release shipped with, not upgrading to a new upstream version — which is why an LTS keeps a stable API surface for five years while still being patched. ## Point releases An LTS gets **point releases** roughly every six months for the first couple of years: `24.04.1`, `24.04.2`, and so on. A point release is not a new release you upgrade "to" — a machine that keeps up with updates is already at the point release. What changes is the **installation media**: refreshed ISOs and cloud images that roll up all published updates and, on desktop, a newer enabled hardware kernel, so a fresh install does not have to download two years of patches. The `.1` matters for a second reason. Ubuntu does not offer LTS-to-LTS upgrades to existing LTS users until the first point release of the target is out; the behaviour is governed by the `Prompt=` setting in `/etc/update-manager/release-upgrades`, whose default on LTS installs is `lts`. That is why the folk rule "wait for the .1" exists. ## Codenames are the machine-readable identity Each release also has a codename: an adjective and an animal starting with the same letter, advancing alphabetically — bionic, focal, jammy, noble. It is decoration for humans, but it is load-bearing for machines: APT sources name the **series** by codename, and a package repository or PPA publishes builds per series. This is why a third-party repository that has no build for your codename gives you nothing at all, and why the codename appears in `/etc/os-release` as `VERSION_CODENAME`. ## Choosing for a fleet The practical decision rule: **servers run LTS**, and you plan the upgrade before the five-year clock runs out, not after. Standardising an entire fleet on one LTS is what makes configuration management, base images and security patching tractable; running a mix of interim releases means every machine ages out on its own schedule. If you need software newer than the LTS carries, you get it from a vendor repository, a container image, a snap or the `-backports` pocket rather than by moving the whole machine to an interim release. ``` $ . /etc/os-release; echo "$VERSION_ID $VERSION_CODENAME" 24.04 noble ``` That one line answers both "how old is this box" and "which series do repositories have to target" — the two things the numbering scheme was designed to make obvious.