The release criteria aim to:
- Clearly specify the criteria that must be met for each of our public releases (Alpha, Beta, Final) to ship
- Document all the requirements of our target audience for each Fedora release
- The target audiences for each public release (Alpha, Beta, and Final) can be different, and may overlap
- Establish when a release is "done" in terms that most people can understand and in ways that help new people to understand the process and participate
Having a consistent, public and comprehensive set of release critera should:
- Reduce the need for meetings to be held and subjective decisions made at the last minute
- Help others who are not involved in the release process to understand our goals and objectives
- Reduce the need for "gut level" subjective feelings about whether we are ready to ship or not
- Help us to focus on the purpose of the release and what we are doing it for while focusing less time and energy on things outside of this scope
- Provide an early warning sign if the release is not on track for shipping on time
Release Criteria Specifics
- Release criteria for each public release also provides guidance as to whether a particular bug should block the public availability of a release.
- Release criteria increases in difficulty culminating with the Final Release (GA--General Availability)
- Unique pages for the release criteria are created for each public release
- Release criteria not only reflects acceptable defect levels, it also details acceptable levels of polish
Fedora places a high priority on releasing according to schedule. While, release quality is very important, there are circumstances where the schedule takes priority.
The following priorities, in this order, will define what matters most in completing our releases:
- Target schedule date
- Release quality
- New release features
Bugs can be fixed in package updates and new features can be included in the next release.