Skip to main content

Release Processes

This post is intended as both information to users, and guidelines for developers and contributors of Solus. Solus employs a formal architecture to enable the curated rolling release model, which is made possible through the use of ferryd, solbuild and a split-repository model.

Repository staging​

All package builds for Solus, updates or otherwise, will always enter the unstable repository first. Consequently, all Solus developers and contributors should ensure solbuild is configured to use the unstable target. As and when the weekly stabilization efforts have completed, the unstable repository will be pulled into polaris, the stable target.

This effectively means that polaris is a rolling snapshot of unstable. Note that the weekly sync will not make each repository match identically - the tip of every package in unstable will be merged into polaris. This ensures that the polaris update path is cost-efficient in terms of package availability, and that the delta packages provided on polaris match the true update path for those users. Lastly, this also ensures that there are no unintended packages arriving in Polaris from older builds.

Solus installations always default to the polaris repository, making Polaris the published distribution, and unstable the development distribution.

Weekly Sync - Every Friday​

At minimum there shall be one sync per week - this will always be on a Friday. As a result, users are never more than a few days away from unstable. This allows packagers to make deeper changes to Solus and still have time to stabilize the repository before releasing changes on the Friday.

Given the high volume of changes within Solus in any sync window, the Friday sync should be viewed more as a release than a simple sync. All developers and contributors should try their best to ensure that their changes do not introduce regressions, and that existing update paths are always respected.

Minor syncs during the week, and correctional syncs shortly after the Friday-sync, are permitted assuming they do not introduce breaking changes to polaris. These may include minor packaging changes, security updates, etc.

Package deprecation​

There are times when a package may need to be deprecated or even renamed. Packagers owning these changes must first communicate the need to ensure a coordinated deprecation.

Deprecated packages will remove themselves from the users systems as the first operation in an update or package install using the package manager, once marked as Obsolete in the index.

Deprecating a package​

Follow these steps to submit a package for deprecation:

  1. Create a new branch in the Solus packages repository on GitHub (forking it first if necessary) with a suitable name such as "deprecate-foobar"
  2. Edit repo_data/distribution.xml.in
  3. Add the package you wish to deprecate at the end of the <Obsoletes> section
  4. Change directory to repo_data (cd repo_data), then run the merged_repos.sh script
  5. Remove the package from the Solus packages repository, for example rm -fr packages/f/foobar
  6. Commit and push your changes to your repository/branch
  7. Open a Pull Request on GitHub

Un-deprecating a package​

The above steps also apply to un-deprecating a package, with the following additions:

  1. Create a new branch in the Solus packages repository on GitHub (forking it first if necessary) with a suitable name such as "undeprecate-foobar"
  2. Find the commit deprecating the package and restore the package within the repository structure. For example restore all files in packages/f/foobar or use git revert if appropriate
  3. Edit repo_data/distribution.xml.in and remove the package you wish to undeprecate in the <Obsoletes> section
  4. Change directory to repo_data (cd repo_data), then run the merged_repos.sh script
  5. Open a Pull Request on GitHub and ask a Solus Staff member to use available tooling to update the repository files, then index the repository with ferryctl index unstable (or do it yourself if you have the ability)
  6. Bump or update the package

Major stack changes​

Large stack upgrades should begin as closely to the last Friday sync as possible, to ensure there is plenty of time for the work to be completed, integrated, and tested for regressions.