# Freezes This article provides an overview of the stabilization freezes that lead to the release of a new version of Ubuntu. The series of freezes means the gradual introduction of restrictions on modifications in certain areas, so that the distribution can stabilize as it nears the final release. See [Release cycle](https://documentation.ubuntu.com/project/release-team/release-cycle.md#release-cycle) for an overview of the entire release process. [Freeze exceptions](https://documentation.ubuntu.com/project/release-team/freeze-exceptions.md#freeze-exceptions) can be granted by the [Release Team](https://documentation.ubuntu.com/project/release-team/release-team.md#release-team) in some circumstances. ## Debian Import Freeze **Prior** to the Debian Import Freeze date, new versions of packages are automatically imported from Debian’s `unstable` branch (where they have not been customized for Ubuntu). Entirely new packages (those not in Ubuntu at all) are also automatically imported. The import is done by copying the source package verbatim from Debian and building fresh binary packages on the Ubuntu autobuilders. **After** the Debian Import Freeze date, the Release Team disables the automatic import of new packages and versions from Debian. The import of a new package (or package version) from Debian after the Debian Import Freeze must be explicitly requested by a developer. If the package needs to be modified for Ubuntu, or is not in Debian, then a developer can still upload it directly. ## Feature Freeze During Feature Freeze (FF), Ubuntu developers stop introducing new features, packages, and [API](https://documentation.ubuntu.com/project/how-ubuntu-is-made/concepts/glossary.md#term-API)/[ABI](https://documentation.ubuntu.com/project/how-ubuntu-is-made/concepts/glossary.md#term-ABI) changes, and instead concentrate on fixing bugs in the current release in development (`devel`). Note that the upload queue is not actually frozen – uploads will enter the Archive, so be careful. It is possible to apply for [exceptions](https://documentation.ubuntu.com/project/release-team/freeze-exceptions.md#freeze-exceptions) under some circumstances – such exceptions must be approved by the [Ubuntu Release Team](https://documentation.ubuntu.com/project/release-team/release-team.md#release-team). If in doubt, contact the [Release Team via Matrix](https://matrix.to/#/#release:ubuntu.com) or subscribe `ubuntu-release` to the bug to confirm whether you need an exception or not. ### Bug-fix only updates During FF, updates that *only* contain bug fixes can still be uploaded and don’t need an exception. However, the developer should **explicitly document** that it is a bug-fix only upload in the changelog or sync request. This includes upstream microreleases, which can be verified by reading the detailed upstream changelog, and the diff between the Ubuntu development release version and the new upstream version. ### NEW packages NEW source packages do not require exceptions either, since they must be [checked by Archive Administrators](https://documentation.ubuntu.com/project/maintainers/AA/aa-new-review.md#aa-new-review) before they are included in the Archive. For the purposes of Feature Freeze, the upload date matters – all packages in the NEW queue before Feature Freeze will be processed without needing an exception. If you have a NEW upload that isn’t a sync from Debian, make sure you obtain the agreement of the [Archive Admin](https://documentation.ubuntu.com/project/who-makes-ubuntu/roles/archive-administration.md#archive-administration) team to perform the necessary queue reviews *before* you upload. However, if you integrate the NEW package into an existing one (e.g. by adding a dependency or enabling a feature) or add it to a seed, Feature Freeze applies and you must apply for an exception. #### NOTE General development activity is still unrestricted until the Feature Freeze; however, the Feature Freeze is often scheduled for the same day. ## User Interface Freeze The User Interface (UI) is frozen at this point to allow documentation writers and translators to work on a fixed target, so that screenshots and documentation do not become obsolete while they’re working on it. After the UI Freeze (UIF), the following things are not allowed to change without a [UI Freeze exception](https://documentation.ubuntu.com/project/release-team/freeze-exceptions.md#ui-freeze-exceptions): * 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 At this point, documentation strings should no longer be created or changed. This freeze ensures the documentation can be accurately translated. Exceptions to this rule may be considered before the release for significant and glaring errors or exceptional circumstances. A string change must be discussed (and approved) on the [`ubuntu-doc` mailing list](mailto:ubuntu-doc@lists.ubuntu.com). If a string is changed after the freeze, it must be communicated to the translators (by writing to the `ubuntu-translators` mailing list) *with enough time to update the translations before the [translation freeze](#non-language-pack-translation-deadline)*. After release, any fixes must comply with the [Stable Release Updates](https://documentation.ubuntu.com/project/SRU/howto.md#stable-release-updates) process, and where necessary must be accompanied by translations before uploading. ## Kernel Feature Freeze The [kernel](https://documentation.ubuntu.com/project/how-ubuntu-is-made/concepts/glossary.md#term-Kernel) feature development should end at this point, and the kernels can be considered feature-complete for the release. From now on, only bug-fix changes are expected. #### NOTE The Kernel Feature Freeze occurs after the [Feature Freeze](#feature-freeze) 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](#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. **Before** Beta Freeze, all uploads enter the Archive without any approval. **After** the Beta Freeze date, any changes to packages that will affect beta release images (i.e. seeded packages) require the Release Team’s approval because they’ve entered the unapproved queue after uploading. Uploads for packages that do *not* affect beta release images (un-seeded packages) will still be auto-accepted until [Final Freeze](#final-freeze). So be careful with what you upload. #### TIP Use the tool, provided by the `ubuntu-dev-tools` package, to list all current daily images containing a specified package or to determine whether the specified package is seeded or not. This freeze allows the Release Team to fix package inconsistencies or critical bugs quickly and in an isolated manner. Once the beta release is shipped, we roll back to [Feature Freeze](#feature-freeze) and [User Interface Freeze](#user-interface-freeze) status. ## 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 Team. ## 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 developers time to manually export translations from Launchpad and integrate them into the package. This deadline 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. #### NOTE The [wiki page](https://wiki.ubuntu.com/NonLanguagePackTranslationDeadline) lists the packages this affects: do we want to include this? Other packages can still be translated until the [Language pack translation deadline](#language-pack-translation-deadline). ## Language pack translation deadline Translations done up until this date are included in the final release’s language packs. See the [language pack creation schedule](https://dev.launchpad.net/Translations/LanguagePackSchedule) for more. ## Final Freeze This freeze marks an **extremely** high-caution period until the [Final Release](https://documentation.ubuntu.com/project/release-team/release-cycle.md#final-release). Only bug fixes for release-critical, security-critical or otherwise “exceptional circumstance” bugs are included in the Final Release, which the Release Team and (and the relevant team looking after the package) must confirm. ### Unseeded packages Packages in [universe](https://documentation.ubuntu.com/project/how-ubuntu-is-made/concepts/package-archive.md#archive-components-universe) that aren’t seeded in any of the Ubuntu flavors remain in [Feature Freeze](#feature-freeze) because they do not affect the release. When the Ubuntu Package Archive is frozen, and fixes to [main](https://documentation.ubuntu.com/project/how-ubuntu-is-made/concepts/package-archive.md#archive-components-main) must be manually reviewed and accepted by the Release Team members, a bot takes care of auto-accepting unseeded packages automatically. 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](https://documentation.ubuntu.com/project/SRU/howto.md#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. ## Release Candidate The images produced on the Monday of the release week before [Final Release](https://documentation.ubuntu.com/project/release-team/release-cycle.md#final-release) are usually considered “release candidates”. This is a target, and not an absolute truth. To know which images are considered release candidates, look for the “call for testing” announcement, or ask the Release Team directly. 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. ## Further reading - [Freeze exceptions](https://documentation.ubuntu.com/project/release-team/freeze-exceptions.md#freeze-exceptions) - [Request a Freeze exception](https://documentation.ubuntu.com/project/release-team/request-a-freeze-exception.md#request-a-freeze-exception)