Caution
The Packaging and Development guide is currently undergoing a major overhaul to bring it up to date. The current state you are seeing now is a preview of this effort.
The current version is unstable (changing URLs can occur at any time) and most content is not in properly reviewed yet. Proceed with caution and be aware of technical inaccuracies.
If you are an experienced packager and would like to contribute, we would love for you to be involved! See our contribution page for details of how to join in.
Ubuntu development process¶
Each release cycle follows the same general pattern, with the following major phases. Ubuntu contributors are expected to follow this process closely to ensure that 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.
See also the article Ubuntu releases for more details about the release cadence.
Beginning a new release¶
The Ubuntu infrastructure is prepared for a new development branch at the beginning of each cycle. The package build system is set up, the toolchain is organised, seeds are branched, and many other pieces are made ready before development can properly begin. Once these preparations are made, the new branch is officially announced on the ubuntu-devel-announce mailing list and opened for uploads to the Ubuntu package archive.
Note
See the Ubuntu 24.04 LTS (Noble Numbat) archive opening announcement email as an example.
Planning¶
Ubuntu contributors discuss the targeted features for each release cycle via the various channels (e.g., IRC, 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 (similar but different to the past Ubuntu Developer Summits) 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 characterised by bringing new releases of upstream components into Ubuntu, either directly or via Merges and syncs from Debian. 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.
Stabilisation and milestones (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. Archive admins incrementally restrict modifications to the Ubuntu package archive, effectively freezing the state of the Ubuntu package archive. The milestones when these restrictions get enabled are called “freezes”. During freezes, developers must request exceptions to approve changes. See how to request a freeze exception. The release team usually posts the current Release Schedule as a Discourse article under the “Release” topic. It shows the typical order and length of the various freezes.
Note
In the past, the Release Schedule was published in the Ubuntu Wiki. See, for example, the release schedule of Ubuntu 20.04 LTS (Focal Fossa).
Testing weeks¶
During a release’s development phase, the release team organise testing weeks to focus the Ubuntu community’s efforts on testing Ubuntu’s latest daily ISO images and its flavours. These weeks are crucial for discovering bugs and getting early feedback about new features.
Note
The testing weeks replaced the older practice of alpha and beta milestones. For example, Ubuntu 14.04 LTS (Trusty Tahr) had Alpha 1, Alpha 2, Beta 1, and Beta 2 milestones.
See the email that announced the process change.
Debian Import Freeze¶
Archive admins disable the automatic import of new packages and versions of existing packages from Debian. The import of a new package or version of an existing package from Debian has to be requested.
Note
The general development activity is still unrestricted until the Feature Freeze; however, the Feature Freeze is often scheduled for the same day.
Feature Freeze (FF)¶
At this point, Ubuntu developers should stop introducing new features, packages, and API/ABI changes, and instead concentrate on fixing bugs in the current release in development.
User Interface Freeze (UIF)¶
The user interface should be finalised to allow documentation writers and translators to work on a consistent target that doesn’t render screenshots or documentation obsolete.
After the user interface freeze, the following things are not allowed to change without a freeze exception:
User interface of individual applications that are installed by default
Appearance of the desktop
Distribution-specific artwork
All user-visible strings in the desktop and applications that are installed by default
Documentation String Freeze¶
Documentation strings should no longer be created or modified. This freeze ensures that the documentation can be accurately translated.
Exceptions to this rule may be considered before the release for significant and glaring errors or exceptional circumstances.
Kernel Feature Freeze¶
The kernel feature development should end at this point, and the kernels can be considered feature-complete for the release. From now on, only bugfix changes are expected.
Note
The Kernel Feature Freeze occurs after the Feature Freeze (FF) because the Linux Kernel is typically released upstream after the Feature Freeze. Additionally, the Kernel Feature Freeze is deliberately scheduled so that the Beta images have a fully featured kernel suitable for testing.
Hardware Enablement Freeze¶
All new hardware enablement tasks for devices targeting the given release should be finished, and all the respective packages should be in the Ubuntu package archive. The release team no longer accepts changes in the Ubuntu package archive related to supporting new image types or platforms. This freeze ensures that any new platforms are already available for testing of the beta images and in the weeks leading to the Final Freeze.
Note
The Hardware Enablement Freeze is usually scheduled for the same day as the Beta Freeze.
Beta Freeze¶
In preparation for the beta release, all uploads are queued and subject to manual approval by the release team. Changes to packages that affect beta release images (flavours included) require the release team’s approval before uploading. Uploads for packages that do not affect images are generally accepted as time permits.
Tip
You can use the seeded-in-ubuntu(1) tool, provided by the
ubuntu-dev-tools package, to list all the current daily images
containing a specified package or to determine whether the specified
package is part of the supported seed.
If the list output is empty, uploading it during a freeze should be safe.
The freeze allows Archive Admins to fix package inconsistencies or critical bugs quickly and in an isolated manner. Once the beta release is shipped, the Beta Freeze restrictions no longer apply.
Kernel Freeze¶
The Kernel Freeze is the final date for kernel updates because they require several lockstep actions that must be folded into the image-building process.
Exceptional circumstances may justify exemptions to the freeze at the discretion of the release managers.
Non-language-pack translation deadline¶
Some translation data cannot currently be updated via the language pack mechanism. Because these items require more disruptive integration work, they are subject to an earlier deadline to give time to developers to manually export translations from Launchpad and integrate them into the package.
This marks the date after which translations for such packages are not guaranteed to be included in the final release. Depending on the package and its maintainers workflow, they may be exported later.
Other packages can still be translated until the Language pack translation deadline.
Final Freeze¶
This freeze marks an extremely high-caution period until the Final Release. Only bug fixes for release-critical, security-critical or otherwise exceptional circumstantial bugs are included in the Final Release, which the release team and relevant section teams must confirm.
Unseeded packages¶
Packages in universe that aren’t seeded in any of the Ubuntu flavours remain in Feature Freeze (FF) because they do not affect the release; however, when the Ubuntu package archive is frozen, fixes must be manually reviewed and accepted by the release team members.
When the Final Release is close (~1.5 days out), developers should consider uploading to the proposed pocket, from which the release team cherry-picks into the release pocket if circumstances allow. All packages uploaded to the proposed pocket that do not make it into the release pocket until the Final Release become candidates for Stable Release Updates. Therefore, uploads to the proposed pocket during Final Freeze should meet the requirements of Stable Release Updates if the upload is not accepted into the release pocket. In particular, the upload must reference at least one bug, which is used to track the stable update.
Note
If you are sure that your upload will be accepted during Final Freeze, you can upload directly to the release pocket, but be aware that you have to re-upload after Final Release if the upload gets rejected.
Release Candidate¶
The images produced during the week before the Final Release are considered “release candidates”. In an ideal world, the first release candidate would end up being the Final Release; however, we don’t live in a perfect world, and this week is used to get rid of the last release-critical bugs and do as much testing as possible. Until the Final Release, changes are only permitted at the release team’s discretion and will only be allowed for high-priority bugs that might justify delaying the release.
Language pack translation deadline¶
Translations done up until this date will be included in the final release’s language packs.
Finalisation¶
As the final release approaches, the focus narrows to fixing “showstopper” bugs and thoroughly validating the installation images. Every image is tested to ensure that the installation methods work as advertised. Low-impact bugs and other issues are deprioritised 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. In contrast, ordinary bugs affecting the installed system can be fixed with Stable Release Updates.
Final Release¶
Once the release team declares the Release Candidate ISO stable and names it the “Final Release”, a representative of the team announces it on the ubuntu-announce mailing list.
Note
See, for example, the Ubuntu 24.04 LTS (Noble Numbat) release announcement.
Stable Release Updates¶
Released versions of Ubuntu are intended to be stable. This means that users should be able to rely on their behaviour remaining the same and therefore, updates are only released under particular circumstances.
The dedicated Stable Release Updates (SRU) article describes these criteria and the procedure for preparing such an update.