(tweak categories) |
(hum let's make it 'basic release criteria' plus they apply to rawhide too) |
||
Line 7: | Line 7: | ||
== Criteria for Current Release Milestones == | == Criteria for Current Release Milestones == | ||
* [[Basic Release Criteria]] | |||
* Fedora {{FedoraVersionNumber|next}} - [[Fedora {{FedoraVersionNumber|next}} Beta Release Criteria|Beta]], [[Fedora {{FedoraVersionNumber|next}} Final Release Criteria|Final]] | * Fedora {{FedoraVersionNumber|next}} - [[Fedora {{FedoraVersionNumber|next}} Beta Release Criteria|Beta]], [[Fedora {{FedoraVersionNumber|next}} Final Release Criteria|Final]] | ||
Line 13: | Line 14: | ||
The release criteria aim to: | The release criteria aim to: | ||
* Clearly specify the criteria that ''must'' be met for each of our public releases (Beta | * Clearly specify the criteria that ''must'' be met for each of our public releases (nightly composes, Beta and Final) to ship | ||
* Document all the requirements of our target audience for each Fedora release | * Document all the requirements of our target audience for each Fedora release | ||
** The target audiences for each public release (Beta and Final) can be different, and may overlap | ** The target audiences for each public release (nightly composes, Beta and Final) can be different, and may overlap | ||
** The criteria at any given time are not set in stone: there may be requirements that have been overlooked, or that are new, and in these cases, the criteria should be expanded to ensure all needs are covered | ** The criteria at any given time are not set in stone: there may be requirements that have been overlooked, or that are new, and in these cases, the criteria should be expanded to ensure all needs are covered | ||
* 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 | * 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 | ||
Line 41: | Line 42: | ||
Bugs can be fixed in package updates and new features can be included in the next release. | Bugs can be fixed in package updates and new features can be included in the next release. | ||
== | == Basic Release Criteria == | ||
The [[ | The [[Basic Release Criteria]] have a similar purpose to the Beta and Final release criteria. However, they apply to all Rawhide and Branched nightly composes (as well as all milestone candidate composes). We aim to ensure every nightly compose that is released - in the sense of being synced to the [[Repositories#The_rawhide_repository|''rawhide'' repository]] or the [[Repositories#The_fedora_repository_in_Branched_releases|Branched ''fedora'' repository]] - meets the Basic Release Criteria, using a fully automated process (both the testing and the determination as to whether a compose should be released are automated). The Basic Release Criteria are based on the former Alpha Release Criteria. | ||
== Reference Material == | == Reference Material == |
Latest revision as of 21:17, 1 August 2017
|
Criteria for Current Release Milestones
- Basic Release Criteria
- Fedora 42 - Beta, Final
Purpose
The release criteria aim to:
- Clearly specify the criteria that must be met for each of our public releases (nightly composes, Beta and Final) to ship
- Document all the requirements of our target audience for each Fedora release
- The target audiences for each public release (nightly composes, Beta and Final) can be different, and may overlap
- The criteria at any given time are not set in stone: there may be requirements that have been overlooked, or that are new, and in these cases, the criteria should be expanded to ensure all needs are covered
- 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
Benefits
Having a consistent, public and comprehensive set of release criteria 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
- Make it clear whether a given bug should block the finalization of a release
Release Constraints
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.
Basic Release Criteria
The Basic Release Criteria have a similar purpose to the Beta and Final release criteria. However, they apply to all Rawhide and Branched nightly composes (as well as all milestone candidate composes). We aim to ensure every nightly compose that is released - in the sense of being synced to the rawhide repository or the Branched fedora repository - meets the Basic Release Criteria, using a fully automated process (both the testing and the determination as to whether a compose should be released are automated). The Basic Release Criteria are based on the former Alpha Release Criteria.