The openSUSE maintenance update policy aims to establish a common understanding about what kind of bug qualifies as maintenance update and defines rules for packages to minimize the risk of breaking user systems.
- Security bugs generally qualify for an update unless the bug has very low impact or only affects unusual configurations. The security team evaluates security bugs and helps deciding whether it's worth an update.
- Non Security Bugs: If it makes general sense to release and is worth the effort and risk. Lets give a negative indicator list:
- We cannot fix installation bugs (we cannot release new media).
- If no one would stumble over a bug, it is not necessary to release for an old distribution.
- Package / Code cleanups that would not be visible to regular users.
- Feature development which is better left for the next release.
To reduce the risk of breaking user systems, special care has to be taken when preparing a maintenance update.
- fixes should be applied as small, self-contained patches
- an update must meet user expectations for compatibility and quality
- an update must not break existing package dependencies
- an update should not introduce new package dependencies
- an update should not introduce new (sub-)packages
In some cases it might be sensible to use the a new upstream version instead of applying a patch. For example if the fix is complicated to backport and upstream also only fixes critical bugs in new versions anyways the risk of taking the new version might be lower than producing a broken patch.
Please note that we are not operating openSUSE maintenance as rolling update release at this time, currently please use Tumbleweed for this. (So no version updates for the sake of the version update).
The maintenance team has to be asked to approve version updates.