The Ubuntu lifecycle and release cadence

Canonical publishes new releases of Ubuntu on a regular cadence, enabling the community, businesses and developers to plan their roadmaps with certainty of access to newer open source upstream capabilities.

ubuntu logo

Version numbers are YY.MM

Releases of Ubuntu get a development codename (‘Breezy Badger’) and are versioned by the year and month of delivery - for example Ubuntu 17.10 was released in October 2017.

Long term support and interim releases

LTS or ‘Long Term Support’ releases are published every two years in April. LTS releases are the ‘enterprise grade’ releases of Ubuntu and are utilised the most. An estimated 95% of all Ubuntu installations are LTS releases, with more than 60% of large-scale production clouds running on the most popular OS images - Ubuntu 18.04, 16.04 and 14.04 LTS.

Every six months between LTS versions, Canonical publishes an interim release of Ubuntu, with18.10 being the latest example. These are production-quality releases and are supported for their lifespan, with sufficient time provided for users to update, but these releases do not receive the long-term commitment of LTS releases.

  Released End of Life Extended security maintenance
Ubuntu 22.04 LTS April 2022 April 2027
Ubuntu 21.10 October 2021 July 2022
Ubuntu 21.04 April 2021 January 2022
Ubuntu 20.10 October 2020 July 2021
Ubuntu 20.04 LTS April 2020 April 2025 April 2030
Ubuntu 19.10 October 2019 July 2020
Ubuntu 19.04 April 2019 January 2020
Ubuntu 18.10 October 2018 July 2019
Ubuntu 18.04 LTS April 2018 April 2023 April 2028
Ubuntu 16.04 LTS April 2016 April 2021 April 2024
Ubuntu 14.04 LTS April 2014 April 2019 April 2022
Ubuntu 12.04 LTS April 2012 April 2017 April 2019
Ubuntu 10.04 LTS April 2010 April 2015

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 artifact is likely to be less than the support period of the interim release. Interim releases receive full security maintenance for ‘main’ during their lifespan.

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’ which might be Ubuntu16 or Ubuntu18 (corresponding to the set of minimal debs in Ubuntu 16.04 LTS or Ubuntu 18.04 LTS but can now also include other versions of Linux too. Nevertheless, the choice of base does not impact on your ability to use a snap, 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 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 will include a Minimal Edition which has the fewest possible packages installed, a Server Edition which has a standard set of out-of-the-box usability conveniences, and a Desktop Edition which has the default GUI experience pre-installed. 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.

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).

  Base Packages Extended Packages
Open Source main universe
Not Open Source restricted multiverse

The base system receives a commitment to public maintenance for the period where it is the current LTS or interim release and for a period thereafter.

Customers of Canonical often ask for an extended security maintenance commitment, either to ‘main’ for a longer period of time, or to ‘universe’ software packages during the initial maintenance period of the LTS. This is known as 'Extended Security Maintenance' or ESM and is available for LTS releases since Ubuntu 12.04 LTS.

LTS security maintenance 5 years initial period Further 3 years
main public ESM
universe ESM ESM

Ubuntu LTS releases transition into Extended Security Maintenance (ESM) phase as the standard, five-year public support window comes to a close. It is recommended for users and organisations to upgrade to the latest LTS release or subscribe to ESM for continued security coverage.

This command will print the exact status of your system:

The Ubuntu Releases wiki has current information on previous and upcoming versions.

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 18.04 LTS kernels typically used the 4.15 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 16.04 LTS received the kernels from Ubuntu 16.10, 17.04, 17.10 and 18.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 these ‘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:

Release Released End of life Extended security maintenance
Ubuntu 18.04.5 LTS August 2020 April 2023 April 2028
Ubuntu 20.04 LTS April 2020 April 2025 April 2030
Ubuntu 18.04.4 LTS February 2020 August 2020  
Ubuntu 19.10 October 2019 July 2020  
Ubuntu 18.04.3 LTS August 2019 February 2020  
Ubuntu 19.04 April 2019 January 2020  
Ubuntu 18.04.2 LTS February 2019 August 2019  
Ubuntu 18.10 October 2018 July 2019  
Ubuntu 18.04.1 LTS (v4.15) July 2018 April 2023 April 2028
Ubuntu 16.04.5 LTS (v4.15) August 2018 April 2021 April 2024
Ubuntu 18.04.0 LTS (v4.15) April 2018 April 2023 April 2028
Ubuntu 16.04.1 LTS (v4.4) August 2016 April 2021 April 2024
Ubuntu 14.04.5 LTS (v3.13) August 2016 April 2019 April 2022
Ubuntu 16.04.0 LTS (v4.4) April 2016 April 2021 April 2024
Ubuntu 14.04.1 LTS (v3.13) August 2014 April 2019 April 2022
Ubuntu 12.04.5 LTS (v3.13) August 2014 April 2017 April 2019
Ubuntu 14.04.0 LTS (v3.13) April 2014 April 2019 April 2022
Ubuntu 12.04.1 LTS (v3.2) August 2012 April 2017 April 2019
Ubuntu 12.04.0 LTS (v3.2) April 2012 April 2017 April 2019

For more information on previous and upcoming kernel releases please see the Ubuntu LTS Enablement Stack wiki page.

Ubuntu OpenStack release cycle

Canonical’s Cloud Archive allows users the ability to install newer releases of Ubuntu OpenStack on an Ubuntu server as they become available. A given LTS release of Ubuntu will have the current release of OpenStack packaged in its release archives. The next four releases of OpenStack will then be published in the Cloud Archive for that LTS.

That means that it is possible to upgrade OpenStack four times on the same Ubuntu LTS release base operating system (upgrading the OpenStack without upgrading the operating system), and then one has the same OpenStack version that is included with the subsequent LTS release, and can choose to upgrade the operating system without upgrading the OpenStack version.

The middle OpenStack release (one year after the LTS release and one year before the next LTS release) is maintained for an extended period. Many customers therefore opt to make annual upgrades to their OpenStack rather than tracking each six-monthly release. The actual upgrade is fully supported using Canonical OpenStack tools and operator guides, and involves hopping through the six-monthly versions for database upgrade purposes, but the next effect is an annual upgrade to a version that is fully supportable.

The Ubuntu OpenStack support lifecycle can be represented this way:

Release Released End of life Extended customer support
OpenStack U LTS April 2020 April 2025  
Ubuntu 20.04 LTS April 2020 April 2025  
OpenStack U Feburary 2020 April 2023  
OpenStack T August 2019 February 2021  
OpenStack Stein April 2019 October 2020 April 2022
OpenStack Rocky August 2018 February 2020  
OpenStack Queens LTS April 2018 April 2023  
Ubuntu 18.04 LTS April 2018 April 2023  
OpenStack Queens March 2018 April 2021  
OpenStack Pike August 2017 February 2019  
OpenStack Ocata February 2017 August 2018 February 2020
OpenStack Newton October 2016 April 2018  
OpenStack Mitaka LTS April 2016 April 2021  
Ubuntu 16.04 LTS April 2016 April 2021  
OpenStack Mitaka April 2016 April 2019  
OpenStack Liberty October 2015 April 2017  
OpenStack Kilo April 2015 October 2016 April 2018
OpenStack Juno October 2014 April 2016  
OpenStack Icehouse LTS April 2014 April 2019  
Ubuntu 14.10 LTS April 2014 April 2019  
OpenStack Icehouse April 2014 April 2017  
OpenStack Havana October 2013 July 2014  
OpenStack Grizzly May 2013 August 2014  
OpenStack Folsom September 2012 June 2014  
OpenStack Essex April 2012 April 2017  
Ubuntu 12.04 LTS April 2012 April 2017  

For more information on previous and upcoming Ubuntu OpenStack releases please see the Ubuntu Cloud Archive wiki page.

Charmed Distribution of Kubernetes® release cycle

The release cycle of the Charmed Distribution of Kubernetes (CDK) is tightly synchronised to the release of upstream Kubernetes®. The current release and two prior releases are supported, giving an effective support period of nine months, subject to changes in the upstream release cycle.

The CDK support lifecycle can be represented this way:

Release Released End of life
Kubernetes 1.5 December 2016 September 2017
Kubernetes 1.6 March 2017 December 2017
Kubernetes 1.7 June 2017 March 2018
Kubernetes 1.8 September 2017 July 2018
Kubernetes 1.9 December 2017 September 2018
Kubernetes 1.10 March 2018 December 2018
Kubernetes 1.11 July 2018 March 2019
Kubernetes 1.12 September 2018 July 2019
Kubernetes 1.13 December 2018 September 2019

For more information on previous and current releases of CDK, please see the CDK release notes.