The Fedora Project provides pre-release images for testing. Thank you for helping to test the next release! Your testing efforts improve the general availability release of Fedora for everyone.
2.1. About the release cycle
Fedora generally follows a release cycle that produces two major releases each year. A release receives support in the form of maintenance and security updates until the next version of Fedora is released. A Fedora release will continue to receive updates until one month after the second following release.
One month after Fedora 21 will mark the end of life for Fedora 19. Fedora 21 and Fedora 20 will be actively maintained until the release of Fedora 22, when Fedora 20 will reach the end of its release cycle.
Rather than following a strict calendar, Fedora releases and pre-releases must meet
release criteria specific to each development milestone. This practice means that the release dates may change, and ensures the quality of each release. Your testing ensures that Alpha, Beta, and general availability releases meet these criteria.
2.2. Life Cycle of a Fedora release
A Fedora release transitions through the following stages during its life cycle:
Rawhide
Rawhide is the development branch of Fedora. It is used by testers and maintainers to test compatibility between packages, identify and correct problems with unreleased packages, and test updates too minor or major to go into a stable release.
You should not use Fedora Rawhide unless you are actively engaged in testing and development. General availbility releases provide the latest stable version of software because of the work done by Fedora contributors in Rawhide. Installing packages from Rawhide to get a newer version is not recommended.
Branched
The
Branched repository is created from Rawhide near the beginning of the release cycle. It creates the basis for what will become the next version of Fedora, and is used to create pre-releases.
During this stage of the release cycle, the main Fedora repositories are frozen to allow predictable testing. Package maintainers may still provide updates for their packages, but these updates are held in the
updates-testing repository until the general release. Only updates that resolve release critera related issues progress during this time.
Because of this freeze, and the subsequent release of the freeze after final release, you may have a large number of package updates available immediately after installation. This is normal and expected. For the best experience, you should update your system with any updates as they become available.
Alpha
Installation images and package builds are composed and tested from the Branched repository. The Fedora QA team works first with
Test Compose
images, then with
Release Candidate
images, to refine the product. Once the appropriate criteria are met, an Alpha release is provided to the general public for feedback and testing.
Beta
After dealing with issues identified with the Alpha release, as well as additional release critera, a Beta release is made available to the public. In most cases, the Beta release user experience will closely mirror the upcoming general availability release.
GA
The general availability release is made available to the public after rigorous testing and another set of more stringent release criteria are met. At this time, packages that were held in
updates-testing
during the release freeze are moved into the general updates repository. Other groups in the project make their work available at this time; websites are switched to the new version, announcements and press releases are sent, support volunteers are engaged, and more.
Primary stable release
Until the next version of Fedora goes through the previously mentioned stages to reach GA, for about six months, a Fedora release receives maintenance, security, and minor feature updates. It is the primary product provided to Fedora users, and the most actively supported.
Maintenance release
When the subsequent version of Fedora makes GA, a Fedora release goes into maintenance status. Packages in this release will still receive updates, expecially bugfix and security updates. Feature updates often require newer versions of packages than the
Updates Policy accomodates, so the newest versions of packages are not usually available to maintenance release users.
EOL
After the second general availablity release, a version of Fedora becomes End Of Life (EOL) and is no longer supported. Maintenance release users are provided with a one month period of continued updates, during which you should update your system to either the current maintenance release or latest stable release.
EOL releases
do not receive security updates or bug fixes. Community support venues such as the
Users mailing list or
IRC channels do not assist with issues on EOL systems. You should update your system before it reaches EOL.
2.3. Testing Fedora Pre-releases
Testing of Fedora Pre-releases is performed by the
Fedora Quality Assurance group. If you are testing Fedora 21 Alpha or Beta and providing feedback, you are part of the QA Team!
There are several places to provide your feedback and follow along with testing efforts:
Fedora Testing mailing list - https://lists.fedoraproject.org/mailman/listinfo/test |
Fedora QA IRC Channel - #fedora-qa on Freenode |
Blocker Bug Tracking Application - https://qa.fedoraproject.org/blockerbugs |
Bugzilla - https://bugzilla.redhat.com |
2.4. Pre-Release Release Notes
The Fedora Release Notes are under active development during the pre-release stages of the release cycle. The current copy is maintained on the wiki under
https://fedoraproject.org/wiki/Category:Documentation_beats until the Beta release, when they are moved into a public git repository and processed for presentation and distribution.
If you are testing the Alpha release of Fedora and encounter notable changes, you can help improve the Release Notes by adding to the
appropriate beat. Don't worry too much about presentation or writing ability; the Docs team will appreciate your help in identifying changes and can refine the copy further.
During the Beta release or at any time during the release cycle, you can file a bug at
http://bugzilla.redhat.com/ against the Release Notes to request an addition or correction.
In an existing bug, you can set the fedora_requires_release_note
flag to ?
to bring the issue to the attention of the Docs team for review.
You can also provide feedback and meet with Docs team members in #fedora-docs on Freenode.