NOTE: THIS IS A DRAFT!
Fedora Release Cycle roadmap
This document is a roadmap for a "typical" Fedora release. It includes milestones and deadlines that are important for Fedora package maintainers, testers, early adopters, and the release team.
For more information on Release, see: Fedora Release Engineering
Note that hard dates are not listed, as this is a generic template for any Fedora release, not a specific one.
Terms:
- F(N): The Fedora release that will be released at the end of this roadmap.
- F(N-1): The previous release that was released before this cycle started.
- F(N+1): The next development release after this cycle.
- Maintainer: Person who maintains a package for this development cycle.
- Release team: People who are responsible for making important decisions about the release.
- Freeze: A point during the release cycle after which changes to the repository are limited to specific updates that fix known bugs or problems.
Post F(N-1) release development
A release cycle begins when the previous development branch is copied off to a F(N-1) branch in CVS and the F(N-1) release is released to the world. During this time, new package versions are allowed. In particular this part of the cycle is when major changes in packages or infrastructure should be done.
Maintainers must preserve upgrade paths for users and other functionality, however. Maintainers must coordinate major changes with other maintainers, such as when they want to upgrade a package which is a dependency for other packages. Maintainers should test packages and evaluate potential changes during this time to make the later portions of the release process easier.
1 week + 2 days before test1
1 Week + 2 days before the first test release (test1), the tree is frozen. No new package builds are allowed unless they fix a serious bug or regression and are approved by the release team.
test1
After test1 is released, builds are allowed again. Maintainers should fix any bugs found in the test1 release at this point. New package versions are allowed during this time, including major changes.
1 week + 2 days before test2
1 week + 2 dyas before the second test release (test2), the tree is again frozen. No new package builds are allowed unless they fix a serious bug or regression and are approved by the release team.
At this point all new Features of the release must be in a testable state in the tree. Any that are not are dropped or reverted. Also, at this point all strings are frozen in the packages for which Fedora is the upstream, to allow translation.
test2
After test2 is released, builds are allowed again. Maintainers should fix any bugs found in the test2 release at this point. New package versions are still allowed, but not any that involve major changes.
At this time, any orphan packages still available in the repository are removed. Any dependency issues these removals cause must be fixed before the next freeze.
1 week + 2 days before test3
1 week + 2 days before the third test release (test3), the tree is again frozen. No new package builds are allowed unless they fix a serious bug or regression and are approved by the release team.
test3
After test3 is released, the tree remains frozen. At this time, maintainers should fix any remaining bugs in their packages, and should minimize any other changes to packages.
Pre F(N) release development
During this time, only "stopship" bugs and security issues trigger rebuilds. Only builds approved by the release team are allowed into the tree. At this time, any packages with dependency problems are removed from the tree, and any package that contains upgrade path problems is fixed or dropped by the release team. Any new packages added after this point may not be in the final physical media distribution release
F(N) release
The development branch is copied to a new F-N branch in CVS. The release is pushed out to mirrors and the world and a new cycle begins.
Discussion of important release issues
Orphans
Orphaned packages can occur for a variety of reasons. Refer to http://www.fedoraproject.org/wiki/PackageMaintainers/OrphanedPackages for more information. Maintainers should remove orphaned packages from the development repo when the packages are orphaned. If an orphaned package remains in the repository, it is removed before the test3 freeze, allowing maintainers time to either fix any dependency issues, or decide to take over the orphaned package.
Broken dependencies
Maintainers should strive to avoid broken dependencies in packages at all times. Often broken dependencies result from the upgrade of a dependent package, and a simple rebuild fixes the problem. Sometimes a version increase or even a patch is needed to solve such problems.
All broken package dependencies must be solved before release. In the event a package has broken dependencies one week before the final test release, it may be removed from the repository by the release manager. Note that removal of an orphan package could cause dependency issues in other packages as well. A list of broken dependencies is posted to fedora-devel-list on each package update, and is also sent to the maintainers whose packages have the broken dependencies.
Epoch-Version-Release upgrade path problems
Maintainers should strive to always make a clean upgrade path available to their packages. The development version of each package must always be newer (in RPM terms) than any release version, and each release must provide an upgrade from a previous version. When building updates for a released version, always remember to also rebuild the development version, to preserve the upgrade path. Use the rpmdev-vercmp command to check versions if the upgrade path is not clear.
Maintainers MUST fix packages with upgrade problems by the pre-release freeze. Any packages not fixed may be corrected by the release manager or dropped from the release. A list of packages with Epoch-Version-Release upgrade path problems is regularly posted to the fedora-maintainers-list mailing list.
Mass Rebuilds
During some release cycles ALL packages may need to be rebuilt to take advantage of some new release features. For example a mass rebuild may be triggered by a new compiler feature, a new RPM or packaging feature, or a change that affects how all packages are packaged. If this rebuild is needed for a cycle, it will be done before the test3 freeze.
Release target bugs
Each release has two target bugs associated with it:
- F(N)Target: This is the tracker bug for issues that SHOULD be solved by F(N). For more serious issues, use F(N)Blocker.
- F(N)Blocker: This is the tracker bug for issues that MUST be solved by F(N). For less serious issues, use F(N)Target.
At test3, all Target bugs should be closed, removed or re-assigned to F(N+1). At final freeze, all Blocker bugs should be closed or re-assigned to F(N+1), or the schedule must be modified to allow them to be completed.
Bugzilla
All bugs for the test releases in a devel cycle should be filed against the devel version. At release time, all currently open devel bugs will have a note added asking for the submitter to re-test with F(N). If the bug persists, the version will be changed to F(N). If there is no response from the submitter after a month, the bug will be closed.