The Ubuntu lifecycle and release cadence
Canonical publishes new releases of Ubuntu, OpenStack and Kubernetes on a regular cadence, enabling the community, businesses and developers to plan their roadmaps with the certainty of access to newer open source upstream capabilities.
Long term support and interim releases
Version numbers are YY.MM
Releases of Ubuntu get a development codename ('Lunar Lobster') and are versioned by the year and month of delivery - for example, Ubuntu 23.04 was released in April 2023.
LTS or 'Long Term Support' releases are published every two years in April. LTS releases are the 'enterprise grade' releases of Ubuntu and are used the most. An estimated 95% of all Ubuntu installations are LTS releases.
Ubuntu LTS releases receive 5 years of standard security maintenance for all packages in the ‘Main’ repository. With an Ubuntu Pro subscription you get access to Expanded Security Maintenance (ESM) covering security fixes for packages in the ‘Universe’ repository (esm-apps feature). Additionally, ESM extends the lifetime of an Ubuntu LTS from 5 years to 10 years (esm-infra feature).
Every six months between LTS versions, Canonical publishes an interim release of Ubuntu, with 23.04 being the latest example. These are production-quality releases and are supported for 9 months, with sufficient time provided for users to update, but these releases do not receive the long-term commitment of LTS releases.
|Released||End of Standard Support||End of Ubuntu Pro Support|
|22.10 (Kinetic Kudu)||Oct 2022||Jul 2023|
|22.04 LTS (Jammy Jellyfish)||Apr 2022||May 2027||Apr 2032|
|21.10 (Impish Indri)||Oct 2021||Jul 2022|
|21.04 (Hirsute Hippo)||Apr 2021||Jan 2022|
|20.10 (Groovy Gorilla)||Oct 2020||Jul 2021|
|20.04 LTS (Focal Fossa)||Apr 2020||May 2025||Apr 2030|
|18.04 LTS (Bionic Beaver)||Apr 2018||May 2023||Apr 2028|
|16.04 LTS (Xenial Xerus)||Apr 2016||Apr 2021||Apr 2026|
|14.04 LTS (Trusty Tahr)||Apr 2014||Apr 2019||Apr 2024|
ESM requires Ubuntu Pro subscription.
Interim releases will introduce new capabilities from Canonical and upstream open source projects, they serve as a proving ground for these new capabilities. Many developers run interim releases because they provide newer compilers or access to newer kernels and newer libraries, and they are often used inside rapid devops processes like CI/CD pipelines where the lifespan of an artefact is likely to be less than the support period of the interim release. Interim releases receive full security maintenance for 'main' during their lifespan.
Maintenance and security updates
The debs in Ubuntu are categorised by whether they are considered part of the base system ('main' and 'restricted' are in the base and 'universe' and 'multiverse' are not) and whether they are open source ('main' and 'universe' are, 'restricted' and 'multiverse' are not).
|Ubuntu Base Packages||Community Packages|
|Not Open Source||restricted||multiverse|
For each Ubuntu LTS release, Canonical maintains the Base Packages and provides security updates, including kernel livepatching, for a period of ten years. The lifecycle consists of an initial five-year standard security maintenance period, during which maintenance updates are publicly available without a subscription, and five years of Expanded Security Maintenance (ESM). Furthermore ESM also covers 10 years of security maintenance for the Universe repository, which is not provided outside of Ubuntu Pro subscription. The full 10 year Ubuntu LTS lifecycle is available with an Ubuntu Pro subscription (free for personal use on up to 5 machines).
To check the subscription status of your system, use this command:
The Ubuntu Releases wiki has current information on previous and upcoming versions.
Release components - debs, snaps, images, containers
A release of Ubuntu is made through several different channels. What you consume will depend on where you are and what your interests happen to be.
The heart of Ubuntu is a collection of 'deb' packages which are tested and integrated so that they work well as a set. Debs are optimised for highly structured dependency management, enabling you to combine debs very richly while ensuring that the necessary software dependencies for each deb (themselves delivered as debs) are installed on your machine.
Ubuntu also supports 'snap' packages which are more suited for third-party applications and tools which evolve at their own speed, independently of Ubuntu. If you want to install a high-profile app like Skype or a toolchain like the latest version of Golang, you probably want the snap because it will give you fresher versions and more control of the specific major versions you want to track.
Snaps each pick a 'base', for example, Ubuntu18 (corresponding to the set of minimal debs in Ubuntu 18.04 LTS). Nevertheless, the choice of base does not impact on your ability to use a snap on any of the supported Linux distributions or versions — it's a choice of the publisher and should be invisible to you as a user or developer.
A snap can be strictly confined, which means that it operates in a secure box with only predefined points of access to the rest of the system. For third-party applications, this means that you will have a very high level of confidence that the app can only see appropriate data that you have provided to it. Snaps can also be 'classic' which means that they behave more like debs, and can see everything on your system. You should make sure you have a high level of confidence in the publisher of any classic snap you install since a compromise or bad faith behaviour in that code is not confined to the app itself.
It is also common to consume Ubuntu as an image on a public cloud, or as a container. Ubuntu is published by Canonical on all major public clouds, and the latest image for each LTS version will always include security updates rolled up to at most two weeks ago. You may benefit from installing newer updates than that, but the base image you boot on the cloud should always be the current one from Canonical to ensure that it is broadly up to date and the number of updates needed for full security is minimal.
Canonical also publishes a set of images and containers that you can download for use with VMware or other local hypervisors and private cloud technologies. These include standard Ubuntu images on the Docker Hub and standard images for use with LXD and MAAS. These images are also kept up to date, with the publication of rolled up security updated images on a regular cadence, and you should automate your use of the latest images to ensure consistent security coverage for your users.
Editions, Classic and Core
Each release of Ubuntu is available in minimal configurations which have the fewest possible packages installed: available in the installer for Server, Desktop and as separate cloud images. There are also multiple flavours of desktop Ubuntu corresponding to a number of desktop GUI preferences. All of these images are considered 'Classic' Ubuntu because they use debs as their base and may add snaps for specific packages or applications.
The Ubuntu Core image is an all-snap edition of Ubuntu. It is unusual in that the base operating system itself is delivered as a snap; that makes it suitable for embedded appliances where all the possible apps that might need to be installed are available as strictly confined snaps. Ubuntu Core is an appliance or embedded oriented edition of Ubuntu, not particularly comfortable for humans but highly reliable and secure for large-scale appliance deployments such as IoT and CPE in the telco world.
Ubuntu kernel release cycle
Canonical maintains multiple kernel packages for each LTS version of Ubuntu, which serve different purposes. Several of the kernel packages address the need for kernels with specific performance priorities, for example, the low-latency kernel package. Others are focused on optimisation for a particular hypervisor, for example, the kernel packages which are named after public clouds. You are recommended to use the detailed Ubuntu kernel guide to select the best Ubuntu kernel for your application.
In general, all of the LTS kernel packages will use the same base version of the Linux kernel, for example, Ubuntu 20.04 LTS kernels typically used the 5.4 upstream Linux kernel as a base. Some cloud-specific kernels may use a newer version in order to benefit from improved mechanisms in performance or security that are material to that cloud. These kernels are all supported for the full life of their underlying LTS release.
In addition, the kernel versions from the subsequent four releases are made available on the latest LTS release of Ubuntu. So Ubuntu 18.04 LTS received the kernels from Ubuntu 18.10, 19.04, 19.10 and 20.04 LTS. These kernels use newer upstream versions and as a result, offer an easy path to newer features and newer classes of hardware for many users of Ubuntu. Note however that these kernels 'roll' which means that they jump every six months until the next LTS. Large scale deployments that adopt the 'hardware enablement' or HWE kernels should manage those transitions explicitly. These newer HWE kernels are accompanied by a collection of userspace tools closely tied to the kernel and hardware, specifically X display enablement on newer graphics cards.
The Ubuntu kernel support lifecycle is as follows:
|Kernel version||Ubuntu version||Released||End of life||Expanded security maintenance|
|6.2 kernel||Ubuntu 22.04.3 LTS||Aug 2023||Jan 2024|
|Ubuntu 23.04||Apr 2023||Jan 2024|
|5.19 kernel||Ubuntu 22.04.2 LTS||Feb 2023||Jul 2023|
|Ubuntu 22.10||Oct 2022||Jul 2023|
|5.15 kernel||Ubuntu 22.04.1 LTS||Aug 2022||Apr 2027|
|Ubuntu 20.04.5 LTS||Aug 2022||Apr 2025||Apr 2030|
|Ubuntu 22.04.0 LTS||Apr 2022||Apr 2027||Mar 2032|
|5.13 kernel||Ubuntu 20.04.4 LTS||Feb 2022||Jul 2022|
|Ubuntu 21.10||Oct 2021||Jul 2022|
|5.11 kernel||Ubuntu 20.04.3 LTS||Aug 2021||Jan 2022|
|Ubuntu 21.04||Apr 2021||Jan 2022|
|5.8 kernel||Ubuntu 20.04.2 LTS||Feb 2021||Jul 2021|
|Ubuntu 20.10||Oct 2020||Jul 2021|
|5.4 kernel||Ubuntu 18.04.5 LTS||Aug 2020||Apr 2023||Apr 2028|
|Ubuntu 20.04.1 LTS||Aug 2020||Apr 2025||Apr 2030|
|Ubuntu 20.04.0 LTS||Apr 2020||Apr 2025||Apr 2030|
|4.15 kernel||Ubuntu 16.04.5 LTS||Aug 2018||Apr 2021||Apr 2024|
|Ubuntu 18.04.1 LTS||Jul 2018||Apr 2023||Apr 2028|
|Ubuntu 18.04.0 LTS||Apr 2018||Apr 2023||Apr 2028|
|4.4 kernel||Ubuntu 14.04.5 LTS||Aug 2016||Apr 2019||Apr 2022|
|Ubuntu 16.04.1 LTS||Jul 2016||Apr 2021||Apr 2024|
|Ubuntu 16.04.0 LTS||Apr 2016||Apr 2021||Apr 2024|
|3.13 kernel||Ubuntu 14.04.1 LTS||Jul 2014||Apr 2019||Apr 2022|
|Ubuntu 14.04.0 LTS||Apr 2014||Apr 2019||Apr 2022|
For more information on previous and upcoming kernel releases please see the Ubuntu LTS Enablement Stack wiki page.
OpenStack release cycle
The OpenStack release cadence follows the Ubuntu release cadence. This means that new versions of OpenStack are released twice a year: in April and in October. Those are shipped with new versions of Ubuntu as packages in the Ubuntu Archive.
However, since Canonical recommends using only LTS versions of Ubuntu in production environments, this limits available OpenStack versions to one by default. Therefore, Canonical maintains an additional archive – Ubuntu Cloud Archive – to provide access to newer versions of OpenStack on Ubuntu LTS.
As a result, OpenStack versions that are shipped on Ubuntu LTS by default (aka OpenStack LTS versions) benefit from Canonical's commitment around the Ubuntu Archive, including 5 years of standard security maintenance and Expanded Security Maintenance (ESM) available to Ubuntu Pro and Ubuntu Pro (Infra-only) customers. In turn, OpenStack versions which are shipped on Ubuntu LTS through the Ubuntu Cloud Archive are maintained by Canonical for 18 months only, except for some versions that are maintained for 36 months under Ubuntu Pro and Ubuntu Pro (Infra-only).
OpenStack clouds deployed through Private Cloud Build or validated through Cloud Validation consulting engagement (aka Charmed OpenStack clouds) can also benefit from Full OpenStack support under Ubuntu Pro + Support and Ubuntu Pro (Infra-only) + Support. Full OpenStack support is provided for all OpenStack versions available in the Ubuntu Archive and Ubuntu Cloud Archive during their lifespan under standard security maintenance (18, 36 or 60 months depending on the version).
Charmed OpenStack support lifecycle on Ubuntu can be represented in this way:
|Release||Tech preview||Released||End of life||Extended customer support||Expanded Security Maintenance (ESM)|
|OpenStack 2024.1||Apr 2024||Apr 2027|
|OpenStack 2023.2||Oct 2023||Apr 2025|
|OpenStack 2023.1||Apr 2023||Oct 2024||Apr 2026|
|OpenStack Zed||Oct 2022||Apr 2024|
|OpenStack Yoga LTS||Apr 2022||Apr 2027||Apr 2032|
|Ubuntu 22.04 LTS||Apr 2022||Apr 2027||Apr 2032|
|OpenStack Yoga||Apr 2022||Apr 2025|
|OpenStack Wallaby||Apr 2021||Oct 2022||Apr 2024|
|OpenStack Ussuri LTS||Apr 2020||May 2020||Apr 2025||Apr 2030|
|Ubuntu 20.04 LTS||Apr 2020||Apr 2025||Apr 2030|
|OpenStack Queens LTS||Apr 2018||Apr 2023||Apr 2028|
|Ubuntu 18.04 LTS||Apr 2018||Apr 2023||Apr 2028|
|OpenStack Mitaka LTS||Apr 2016||Apr 2021||Apr 2024|
|Ubuntu 16.04 LTS||Apr 2016||Apr 2021||Apr 2024|
For more information on supported versions, see Charmed OpenStack documentation.
OpenStack clouds deployed with MicroStack can also benefit from Full OpenStack support under Ubuntu Pro + Support and Ubuntu Pro (Infra-only) + Support. Since MicroStack does not use OpenStack packages directly, but rather uses snaps and open container initiative (OCI) images, its support lifecycle is different from Charmed OpenStack.
The first supported version of OpenStack in MicroStack is Antelope. It will be supported until April 2026. Every LTS version of OpenStack will benefit from 10 years of support moving forward. Every second, non LTS version of OpenStack will benefit from 3 years of support moving forward. Only every second version of OpenStack will be supported moving forward. Users will be able to securely upgrade between supported versions of OpenStack using the Skip Level Upgrade Release Process (SLURP) mechanism for 2 years after the next LTS version release.
MicroStack support lifecycle on Ubuntu can be represented this way:
|Release||End of Standard security maintenance||Expanded Security Maintenance (ESM)||Covered with Ubuntu Pro + Support|
|OpenStack 2026.1 LTS||Apr 2026||Apr 2031||Apr 2036||Yes|
|OpenStack 2025.2||Oct 2025||Jul 2026||No|
|OpenStack 2025.1||Apr 2025||Jan 2026||Apr 2028||Yes|
|OpenStack 2024.2||Oct 2024||Jul 2025||No|
|OpenStack 2024.1 LTS||Apr 2024||Apr 2029||Apr 2034||Yes|
|OpenStack 2023.2||Oct 2023||Jul 2024||No|
|OpenStack 2023.1||Jun 2023||Jan 2024||Apr 2026||Yes|
For more information on supported versions, see MicroStack documentation.
Canonical Kubernetes release cycle
The release cycles of Charmed Kubernetes and MicroK8s are tightly synchronised to the release of upstream Kubernetes®. The current release and two prior releases are supported (N-2), subject to changes in the upstream release cycle. Canonical also provides expanded security maintenance (ESM) for N-4 Kubernetes releases in the stable release channel.
For Ubuntu Pro support, users must upgrade to remain in the N-2 support window.
ESM support includes fixes to high and critical CVEs related to Kubernetes charms and MicroK8s (snap), in the current N-4 support window. Upstream updates and fixes to Kubernetes binaries or container images are absorbed by Charmed Kubernetes and MicroK8s.
The Canonical Kubernetes support lifecycle can be represented this way:
|Release||Released||End of N-2 Support||End of N-4 ESM Support|
|1.27.x||April 2023||April 2024||Dec 2024|
|1.26.x||Dec 2022||Dec 2023||Aug 2024|
|1.25.x||Sep 2022||Aug 2023||May 2024|
|1.24.x||May 2022||May 2023||Dec 2023|
|1.23.x||Dec 2021||Dec 2022||Aug 2023|
|1.22.x||Sep 2021||Sep 2022||May 2023|
|1.21.x||Apr 2021||May 2022||Dec 2022|
|1.20.x||Dec 2020||Dec 2021||Sep 2022|
|1.19.x||Sep 2020||Sep 2021||May 2022|
|1.18.x||Apr 2020||Apr 2021||Dec 2021|
|1.17.x||Dec 2019||Dec 2020||Sep 2021|
|1.16.x||Sep 2019||Sep 2020||Apr 2021|
|1.15.x||Jun 2019||Apr 2020||Dec 2020|
|1.14.x||Mar 2019||Dec 2019||Sep 2020|