AOSC Wiki / Developer / Packaging / .
Also available in:

Known Patch Release Rules

Useful list of release rules that defines packages that could be updated in the Stable channel

Attention: This guideline has been deprecated from October 25, 2020. We've switched to a newly-proposed Topic-Based Maintenance Guidelines; please refer to that document instead.

Description

The AOSC OS "Stable" channel under the new TODO: SEASONAL UPDATE MODEL requires that only packages with known patch-level release rules could be updated in this channel, for example, when GNOME Terminal (gnome-terminal) is to be update from 3.30.0 to 3.30.1, this is permitted, as we know that this is a patch release as dictated by GNOME - on the contrary, an update from 3.30.0 to 3.31.0 (stable to unstable) or even from 3.30.0 to 3.32.0 (stable to next-stable) are not acceptable.

Presented below is a table that defines all known patch release rules for upstream projects, if it isn't found here, do not push any updates to the "stable" channel - or these updates will be reverted. However, do note that all packages listed in the list of Exceptions could be updated in the "Stable" channel without consulting the table below.

Table of Known Update Rules

Project or Package NameRule Description
GNOME Desktop and ComponentsIf projects have versions, say, x.y.z or even at times x.y.z.n, then any updates to z or n could be regarded as patch-level releases. y must be even numbers. Source.
KDE FrameworksIf projects have versions, say, x.y.z or even at times x.y.z.n, then any updates to z or n could be regarded as patch-level releases. y may be even or odd numbers. Source.
Plasma Desktop and ComponentsIf projects have versions, say, x.y.z or even at times x.y.z.n, then any updates to z or n could be regarded as patch-level releases. y may be even or odd numbers. Source.
KDE ApplicationsIf projects have versions, say, x.y.z or even at times x.y.z.n, then any updates to z or n could be regarded as patch-level releases. y may be even or odd numbers. Source.
MATE Desktop and ComponentsIf projects have versions, say, x.y.z or even at times x.y.z.n, then any updates to z or n could be regarded as patch-level releases. y must be even numbers. Source.
XFCE Desktop and ComponentsIf projects have versions, say, x.y.z or even at times x.y.z.n, then any updates to z or n could be regarded as patch-level releases. y must be even numbers. Source.
PostgreSQLVersions usually formatted as x.y, where y is considered the patch-level version. Updates, say, from 10.4 to 10.5 is acceptable as a patch-level update. Source.
OpenSSLVersions usually formatted as x.y.z(n), where (n) is usually a Latin letter that indicates the patch-level version. Updates, say, from 1.0.2o to 1.0.2p is acceptable as a patch-level update. Source
BindVersions usually formatted as x.y.z-P(n), where (n) is an integer, which represents the patch-level. Additionally, only when y is an even number should the version be considered as stable. Source.
NginxIf projects have versions, say, x.y.z or even at times x.y.z.n, then any updates to z or n could be regarded as patch-level releases. y must be even numbers. Source.
Telegram DesktopVersion usually formatted x.y.z, updates to z could be regarded as patch-level releases, but only if this particular release is not marked as "Pre-release". Source.
DarktableIf projects have versions, say, x.y.z or even at times x.y.z.n, then any updates to z or n could be regarded as patch-level releases. y must be even numbers.
VileVersions usually formatted as x.y(n), where (n) is usually a Latin letter that indicates the patch-level version. Updates, say, from 9.8s to 9.8t is acceptable as a patch-level update.
NautyVersions usually formatted as x.y*r*(n), where (n) is an integer that indicates the patch-level version. Updates, say, from 2.6r10 to 2.6r11 is acceptable as a patch-level update.
PCRE (8.x)This series of PCRE is now under bugfix-only maintenance, and therefore any updates in the 8.x channel should be considered patch-level. Source
TmuxVersions usually formatted as x.y(n), where (n) is usually a Latin letter that indicates the patch-level version. Updates, say, from 2.3 to 2.3a is acceptable as a patch-level update.
CephVersions usually formatted as x.y.z , then any updates to z could be regarded as patch-level releases. x must be even numbers.
Intel Threading Building BlocksVersions usually formatted as YYYY_U(n), where (n) is an integer, which represents the patch-level.
Semantic Versioning, in generalIf projects have versions, say, x.y.z or even at times x.y.z.n, then any updates to z or n could be regarded as patch-level releases. may be even or odd numbers, unless otherwise specified, like in the example of GNOME. Source.

Table of Known Unreliable Update Rules

The packages and projects found below should never be updated via the Stable channel.

Project or Package NameNote
Deepin Desktop Environment and ApplicationsNo predictable release and versioning model - as suggested one Deepin developer.
LibQalculateFrom 2.6.1 to 2.6.2, for instance, .so version changed from 18 to 19, breaking ABI compatibility. This does not comply with Semantic Versioning.
Trinity Desktop Environment and ApplicationsAn apparently patch-level release, say, from R14.0.4 to R14.0.5 may introduce changes to build system and mix in a large amount of feature updates.
HDF5 (Hierarchical Data Format)Patch release update changes sover, for example, 1.10.1 contains libhdf5.so.101, and 1.10.3, which should have been a patch release update, contains libhdf5.so.103, breaking binary compatibility.