Fedora Release Criteria

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Release Criteria Specifics)
(make Fedora numbers increment automagically)
 
(12 intermediate revisions by 8 users not shown)
Line 1: Line 1:
{| border="1px #222222" cellpadding="0" cellspacing="0" align="center" width="90%" style="background-color:#EEEEEE;"
+
{{autolang|en|es|base=yes}}
|-
+
 
| <div style="margin: 1ex 2em 1ex 2em;"><blockquote><div style="font-size:87%; color: #202020;">You can't know if you're ready to release unless you know what ''done'' means.<br>
+
{{Quote|You can't know if you're ready to release unless you know what ''done'' means.<br>
 
....<br>
 
....<br>
When you use release criteria to know when a project is done, you have taken potentially hidden decisions and made them public and clear.  Make your release criteria objective and measurable, so everyone on the project knows what they're working towards.  Use the criteria as you progress through the project and up to the final release.  Then you can say 'Release it!' with pride.
+
When you use release criteria to know when a project is done, you have taken potentially hidden decisions and made them public and clear.  Make your release criteria objective and measurable, so everyone on the project knows what they're working towards.  Use the criteria as you progress through the project and up to the final release.  Then you can say 'Release it!' with pride.|[http://www.universityalliance.com/info1/whitepapers/villanova/pdfs/WP_VU_ReleaseCriteriaGoodtoGo.pdf Johanna Rothman]}}
  
Also, ponies.</div></blockquote>
+
== Current Release Milestones ==
 +
 
 +
* Fedora {{FedoraVersionNumber|next}} - [[Fedora {{FedoraVersionNumber|next}} Alpha Release Criteria|Alpha]], [[Fedora {{FedoraVersionNumber|next}} Beta Release Criteria|Beta]], [[Fedora {{FedoraVersionNumber|next}} Final Release Criteria|Final]]
  
<div style="float: right; margin: 1.5ex 5em 1ex;">[http://www.universityalliance.com/info1/whitepapers/villanova/pdfs/WP_VU_ReleaseCriteriaGoodtoGo.pdf Johanna Rothman]</div></div>
 
|}
 
<br>
 
 
== Purpose ==
 
== Purpose ==
  
Line 17: Line 16:
 
* 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 (Alpha, Beta, and Final) can be different, and may overlap
 
** The target audiences for each public release (Alpha, 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
 
* 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 ==
 
== Benefits ==
  
Having a consistent, public and comprehensive set of release critera should:
+
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
 
* Reduce the need for meetings to be held and subjective decisions made at the last minute
Line 29: Line 29:
 
* Provide an early warning sign if the release is not on track for shipping on time
 
* 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
 
* Make it clear whether a given bug should block the finalization of a release
 
 
 
== Public Releases ==
 
* [[Fedora_13_Alpha_Release_Criteria |Fedora 13 Alpha Release Criteria]]
 
* [[Fedora_13_Beta_Release_Criteria |Fedora 13 Beta Release Criteria]]
 
* [[Fedora_13_Final_Release_Criteria |Fedora 13 Final Release Criteria]]
 
  
 
== Release Constraints ==
 
== Release Constraints ==
Line 54: Line 47:
 
* http://www.ddj.com/architect/184415651
 
* http://www.ddj.com/architect/184415651
  
[[Category:QA]]
+
[[Category:Release Criteria]]

Latest revision as of 17:25, 16 August 2012

You can't know if you're ready to release unless you know what done means.

....

When you use release criteria to know when a project is done, you have taken potentially hidden decisions and made them public and clear. Make your release criteria objective and measurable, so everyone on the project knows what they're working towards. Use the criteria as you progress through the project and up to the final release. Then you can say 'Release it!' with pride.


Contents

[edit] Current Release Milestones

[edit] Purpose

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
    • 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

[edit] 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

[edit] 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:

  1. Target schedule date
  2. Release quality
  3. New release features

Bugs can be fixed in package updates and new features can be included in the next release.

[edit] Reference Material