Release Criteria

From The Document Foundation Wiki
Jump to: navigation, search

Libreoffice uses time based release plan. It does not wait for either features, or bug fixes - but is based (as purely as possible) on time. This enforces discipline in introducing fixes, gives predictability, and allows more regular releasing. Such model have been shown to produce the best quality Free software.

The time based release makes happy all type of users. Enthusiasts start using X.Y.0 releases with lovely new features and known bugs. While more conservative users are later attracted by the frequent pure bug fix releases. Even the most conservative users is satisfied by a later bug fix releases, e.g. X.Y.3.


Release candidate can be marked as final when:

  • is publicly available for at least 10 days and no blocker bug is reported

Blocker Bug Nomination

If you think that a bug fulfills the below criteria, simply set the severity: blocker and add a comment explaining your decision. See also the current list of blocker bugs.

If a bug is pretty serious but not a blocker, you might want to mark it as Most Annoying Bug (MAB).

Blocker Bug Definition

Any software has bugs. All bugs can't be fixed otherwise the product would never get released. Bugs that could block the release must have one of the following symptoms:

  • app can not be installed
  • app does not start
  • data loss
  • crash
  • freeze
  • security bug
  • license problem
  • unusable function

Also some normal bugs might have the above symptoms. The real blockers must fulfill also the following conditions:

  • problem must be reproducible by more users; if it is not reproducible, it is most likely a problem on the user side; also developers need more information from the reporter; it is not fair to block the release and all users if the reporter does not provide the needed information on time
  • broken functionality must be regression against the last released version; if it was not reported early, it is a rarely used function and the fix could wait until the next release;
  • data loss in import/export filters must be regression against released versions; LibO has very good import/export filters from/into many file formats; they are improved in every release but they are never 100%; sometimes they even depend on a missing functionality; if the problem is not a regression, it is considered as a feature and thus it is not a blocker
  • problem must affect most users or there must not be a reasonable workaround; it is bad to block the release and all users because of a corner case when a reasonable workaround exists

Note that the above definition can not be taken too strictly. Every nominated bug will be considered per basis on the libreoffice mailing list. This does not mean that other bugs are not fixed during the release candidate phase. If the release is blocked, anyone could still add safe fixes for other critical bugs.