If approved by FESCo, push pre-release versions of low level packages. FESCo approves certain packages, including (but not limited to) `glibc` and `gcc`, to provide pre-release versions here. The benefits of the early real-world testing of and upstream collaboration on these key packages far exceeds the risks that they may introduce.
Update Flow
Branched release
A link:https://fedoraproject.org/wiki/Releases/Branched[Branched] release exists for part of the development cycle. It starts as a fork of Rawhide and eventually becomes the next stable release. All successfull branched composes should meet the link:https://fedoraproject.org/wiki/Basic_Release_Criteria[Basic Release Critera].
Branched releases use the update feedback system (link:https://bodhi.fedoraproject.org[Bodhi]): at first just like Rawhide (updates are automatically created when a build finishes, tests run and builds are automatically pushed into the next compose), but then after <<updates-testing-activation>> they switch to using it as stable releases do (maintainers must create updates and submit them for testing, etc).
There are several phases that a branched release goes through that affect what updates can and should be done. In general maintainers should keep in mind that this tree is being stabilized for the next release, so changes should be careful and considered and heading toward stability.
After branching, there are three freezes, <<post-branch-freeze>>, <<beta-freeze>>, and <<final-freeze>>.
Post-branch Freeze
Once the new release is branched off Rawhide, the flow of updates through Bodhi is stopped until there has been a successful branched compose. This period usually lasts just a few days. Release engineering may pass some updates to stable to get the compose to complete, but otherwise all updates are paused until this initial branched compose is completed. This is to make sure we have a compose to build on and aren't dealing with problems landing in new updates before we are ready for them.
Before Updates-testing Activation
For a short time after branching but before the <<beta-freeze>>, the Branched release works like Rawhide: builds submitted by packagers are considered _stable_ after passing through any gating tests via a Bodhi update, and are sent to the link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_] repository directly in the next nightly compose. There are no restrictions beyond those for Rawhide at this point, but maintainers SHOULD be thinking about stabilization from this point onward, and making sure their packages will be in good condition well in advance of the stable release.
Repos available: link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_]
Updates-testing Activation
At this point, the Bodhi update system is changed for the branched release to behave as it does for stable releases (see below) instead of Rawhide. From this point onward maintainers must create updates before packages become available to users and updates pass through link:https://fedoraproject.org/wiki/QA:Updates_Testing[_updates-testing_] to allow for feedback. Updates are moved from link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_] repository to link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_] repository after appropriate karma requirements have been reached. Bodhi sets reasonable defaults for karma and enforces minimum requirements for updates. <<karma-requirements>> for updates are described below.
Repositories available: link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_], link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]
Maintainers SHOULD:
Avoid ABI/API changes where possible. If unavoidable, use a side-tag to rebuild packages.
Avoid any change that breaks composes of Live media, install media or testing.
Land any packages required for Changes planned for that release.