Beta Freeze
This freeze is scheduled to run for the three weeks leading up to the release date, but lasts until the release is signed off, even if it is delayed. During the freeze builds will not be marked _stable_ and moved from link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_] to link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_] (and hence included in the milestone release composes) except for those approved under the Fedora QA team link:https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process[blocker bug process] or link:https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process[freeze exception bug process]. Once the beta release is made, the freeze is lifted. The link:https://fedoraproject.org/wiki/Milestone_freezes[Milestone freezes] page provides more details and is the canonical reference in case of any conflict.
Once the Beta Freeze starts, we are attempting to stabilize the major versions of software that will be shipped with the final release of the OS. Major updates can be tolerated, but breaking things for early testers should be avoided if possible.
During this period:
All updates pulled into the release MUST fix an accepted blocker or freeze exception bug.
All updates still go to link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_].
Beta to Final Freeze
This is the time between the Beta release and the <<final-freeze>>. The branched tree should now be stabilized and prepared for release. Major changes should be avoided during this period. Bear in mind that in most cases, the state your package has reached in the stable link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_] repository at the time of the Final Freeze is the state it will be in for the final release.
Final Freeze
This freeze leads to the creation of the final release. It is similar to the <<beta-freeze>> described above and follows the same update rules.
The link:https://fedoraproject.org/wiki/Repositories#updates[_updates_] repository is enabled at some point during this time, and packages other than freeze exception / blocker fixes are queued for so called "zero day" updates, meaning they will be available in the _updates_ repository at the time of the release (day zero).
Repositories available: link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_], link:https://fedoraproject.org/wiki/Repositories#updates[_updates_], link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]
Once the link:https://fedoraproject.org/wiki/Repositories#updates[_updates_] repository is available, builds marked as _stable_ will go there instead of to link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_].
Stable Releases
Releases of the Fedora distribution are like releases of the individual packages that compose it. A major version number reflects a more-or-less stable set of features and functionality. As a result, we should avoid major updates of packages within a stable release. Updates should aim to fix bugs, and not introduce features, particularly when those features would materially affect the user or developer experience. The update rate for any given release should drop off over time, approaching zero near release end-of-life; since updates are primarily bugfixes, fewer and fewer should be needed over time.
This necessarily means that stable releases will not closely track the very latest upstream code for all packages. We have Rawhide for that.
Updates should be carefully considered with respect to their dependencies. An update that required (or provided) a new Python ABI, for example, would almost certainly not be allowed. ABI changes in general are very strongly discouraged, they force larger update sets on users and they make life difficult for third-party packagers. Additionally, updates that convert resources or configuration one way (i.e., from older->newer) should be approached with extreme caution as there would be much less chance of backing out an update that did these things.
Whenever possible packagers should work with upstream to come up with stable branch releases or common patches for older releases, particularly when updating would require large dependency chain updates.
Repositories available: link:https://fedoraproject.org/wiki/Repositories#fedora[_fedora_], https://fedoraproject.org/wiki/Repositories#updates[_updates_], link:https://fedoraproject.org/wiki/Repositories#updates-testing[_updates-testing_]