Skip to content

Update lifecycle

Updates in this SIG are meant to be temporary: we want our packages to expire.

Tracking

Each package the SIG ships has an open tracking issue in its GitLab project, linking the merge request it comes from. The issue is closed only when the package is retired, which keeps the set of active updates visible and makes bulk cleanups easier.

Retirement

An update is retired once CentOS Stream catches up:

  • If the merge request is merged and released, the stock Stream build sorts higher than the SIG's ~proposed build and replaces it on update. The SIG's build is then untagged and the tracking issue closed.
  • If Stream ships a newer build without the fix (for example because the merge request was closed without being merged), the stock package overtakes the SIG's build. Whoever maintains the update then decides whether to rebase the change onto the new Stream build or to retire it.

The SIG also reviews all its packages periodically, for example at each RHEL point release.

Version numbers

At first, updates do not bump the version: we stick to fixes that can be backported to the version Stream ships. If a version bump is needed, it requires some indication from the Stream or RHEL maintainers that the new version will land in Stream soon (say, by the next minor release), and the release should start at 0.x.