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
Set severity: blocker, add comment and dependency to the meta bug:
|Release Version||Task Meta Bug||Blocker bugs||Most annoying bugs||Remarks|
|LibO-3.3.5 or last release in 3.3 branch||none||Annoying bugs||EOL|
|LibO-3.4||meta bug tdf#35673||blocker bugs (*)||annoying bugs (**)|
|LibO-3.5||meta bug tdf#37361||blocker bugs (*)||annoying bugs (**)|
|LibO-3.6||meta bug tdf#44446||blocker bugs (*)||annoying bugs (**)|
(*) Check also all blocker bugs.
IMPORTANT: The meta bug is called most annoying bugs. It lists bugs that annoys many people and should get fixed in the given X.Y release. It helps developers to prioritize work but most of the bugs does not affect the date of the release. Only bugs with the severity blocker might stop the release.
Note that comments are automatically sent the libreoffice mailing list.
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
- 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.