# Release cycle Each [Ubuntu release](https://documentation.ubuntu.com/project/release-team/ubuntu-releases.md#ubuntu-releases) cycle follows the same general pattern with a number of major phases. Ubuntu contributors are expected to follow this process closely to ensure their work is aligned with that of others. Because of the time-based release cycle, Ubuntu contributors must coordinate well to produce an on-time release. For every release, key dates are set out in the release schedule ([the 24.04 LTS (Noble Numbat) release schedule](https://documentation.ubuntu.com/release-notes/24.04/schedule/) provides an example). ## Beginning a new release The Ubuntu infrastructure is prepared for a new development branch at the start of each cycle. The package build system is set up, the toolchain is organized, [seeds](https://documentation.ubuntu.com/project/how-ubuntu-is-made/concepts/glossary.md#term-Seeds) are branched, and many other pieces are made ready before development can properly begin. Once these preparations are made, the new development release is officially announced on the [`ubuntu-devel-announce`](https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce) mailing list and opened for uploads to the [Package Archive](https://documentation.ubuntu.com/project/how-ubuntu-is-made/concepts/package-archive.md#package-archive). #### NOTE See the Ubuntu 24.04 LTS (Noble Numbat) [Archive opening announcement email](https://lists.ubuntu.com/archives/ubuntu-devel-announce/2023-October/001341.html) as an example. ## Planning Ubuntu contributors discuss the targeted features for each release cycle via the various channels (Matrix, Discourse, Launchpad). Some of these come from strategic priorities for the distribution as a whole, and some are proposed by individual developers. The broader open-source community gets together at the [Ubuntu Summit](https://documentation.ubuntu.com/project/how-ubuntu-is-made/concepts/glossary.md#term-Ubuntu-Summit) (similar but different to the past [Ubuntu Developer Summits](https://documentation.ubuntu.com/project/how-ubuntu-is-made/concepts/glossary.md#term-Ubuntu-Developer-Summit)) to share experiences and ideas, and to inspire future projects covering development as well as design, writing, and community leadership with a wide range of technical skill levels. ## Merging with upstream and feature development The first phase of the release cycle is characterized by bringing new releases of [upstream](https://documentation.ubuntu.com/project/how-ubuntu-is-made/concepts/glossary.md#term-Upstream) components into Ubuntu, either directly or via [Merges & syncs](https://documentation.ubuntu.com/project/how-ubuntu-is-made/processes/merges-and-syncs.md#merges-syncs). The development of planned projects for the release often begins while merging is still underway, and the development accelerates once the Package Archive is reasonably consistent and usable. The automatic import of new package versions from Debian ends at the [Debian Import Freeze](https://documentation.ubuntu.com/project/release-team/freezes.md#debian-import-freeze). ## Monthly snapshots During a release’s development phase, the [Canonical Release Management](https://launchpad.net/~canonical-ubuntu-qa) team organizes [monthly snapshot releases](https://discourse.ubuntu.com/t/supercharging-ubuntu-releases-monthly-snapshots-automation/61876). These releases are not intended to be used in production, but rather are curated, testable milestones that can be used to detect failure modes during the development cycle. Throughout the release cycle, the Release Team tracks milestone tasks using checklist cards in Jira. These checklists are generated from YAML templates maintained in the [ubuntu-release-tools templates repository](https://code.launchpad.net/~ubuntu-release/ubuntu-release-tools/+git/templates/+ref/main). If a milestone checklist needs to be updated, the templates are the source of truth. ## Stabilization and Freezes Developers should increasingly exercise caution in making changes to Ubuntu to ensure a stable state is reached in time for the final release date. The Release Team incrementally restricts modifications to the Ubuntu Package Archive. The dates when these restrictions get enabled are called “Freezes”. During freezes, developers must request [Freeze exceptions](https://documentation.ubuntu.com/project/release-team/freeze-exceptions.md#freeze-exceptions) to approve changes. The Release Team posts the current Release Schedule as a Discourse article under the [“Release” topic](https://discourse.ubuntu.com/c/project/release/38). It shows the typical order and length of the various Freezes. See [Freezes](https://documentation.ubuntu.com/project/release-team/freezes.md#freezes) for an overview of the individual stabilization Freezes. ## Finalization As the [Final Release](#final-release) approaches, the focus narrows to fixing “showstopper” bugs and thoroughly validating the installation images. Every image is tested to ensure the installation methods work as advertised. Low-impact bugs and other issues are deprioritized to focus developers on this effort. This phase is vital, as severe bugs that affect the experience of booting or installing the images must be fixed before the Final Release. By contrast, ordinary bugs affecting the installed system can be fixed with [Stable Release Updates](https://documentation.ubuntu.com/project/SRU/howto.md#stable-release-updates). ## Final Release Once the Release Team declares the [Release Candidate](https://documentation.ubuntu.com/project/release-team/freezes.md#release-candidate) ISO stable and names it the “Final Release”, a representative of the team announces it on the [`ubuntu-announce`](https://lists.ubuntu.com/archives/ubuntu-announce/) mailing list. #### NOTE See, for example, the Ubuntu 24.04 LTS (Noble Numbat) [release announcement](https://lists.ubuntu.com/archives/ubuntu-announce/2024-April/000301.html). ## Flavor expectations [Ubuntu flavors](https://documentation.ubuntu.com/project/how-ubuntu-is-made/concepts/glossary.md#term-Ubuntu-flavors) are community-maintained variants of Ubuntu that ship with different default application sets and desktop environments. Flavor leads play an important role in the release cycle and are expected to coordinate closely with the Release Team. The Release Team expects flavor leads to: - **Acknowledge and drive** the upcoming development cycle for their flavor, including confirming that they intend to participate in the release. - **Monitor and fix** issues related to their flavor image builds throughout the cycle, ensuring images are buildable and installable at each milestone. This is a shared responsibility with the Release Team, depending on how flavor-specifc the issues are. - **Respect freeze deadlines** (feature freeze, UI freeze, beta freeze, etc.) by coordinating with their development team to avoid unapproved changes during freeze periods. - **Be available around key dates** (beta, final freeze, final release) for artifact testing and release approval. - **Communicate proactively** if anything deviates from the usual plan, including last-minute major version bumps, lack of availability, changes in leadership, or any other situation that may affect the release timeline. Flavor leads are free to delegate some of those tasks within their team, as long as they inform the Release Team. The key and spirit of these expectations really is communication. Failure to meet these expectations may result in a flavor not being included in a given release.