AOSC Wiki / Developer / Packaging / .
Also available in: 简体中文

AOSC OS Maintenance Guidelines (Deprecated)

General Procedural Guidlelines for AOSC OS Package Maintenance

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.


AOSC OS is a multi-branch, seasonal rolling Linux distribution available with over 5,000 packages for multiple microprocessor architectures. As such, maintaining AOSC OS is not a trivial task, and all maintainers should work in accordance to a written guideline to avoid confusion and (the resulting) inconsistent quality.

The Branches, Cycles, and Ports

The concepts of branches, cycles, and ports are three main aspects that maintenance work revolves around. In this section, we will defines these concepts in the scope of AOSC OS.

The Branches

AOSC OS is maintained concurrently across four branches:

The Cycles

AOSC OS is maintained on an seasonal cycle, and thus revolves around a three-month schedule:

The Ports

AOSC OS is available for many different microprocessor architectures (and thus many different kinds of devices). While some ports will received full-feature packages, there are distinctions based on the nature of the ports. Here below is a brief description:

In Practice

This section describes the detailed procedures, which AOSC OS maintainers should adhere to.

The Tools

The standard set of tools should be used by all maintainers. While we are unable to track the tools you've used (yet), these set of tools are known to generate the cleanest and most reproducible packages so far.

You will also need a LDAP identity to upload packages and to gain access to our relay servers, or Buildbots.

For the detailed packaging procedures, please refer to the AOSC OS Cadet Training (Work In Progress) and the AOSC OS Package Styling Manual.

The Buildbots

While you are welcome to use your own devices for packaging (given that you are using the tools above), there are fast machines provided by community members, and made available for maintainers.

For more details on gaining access and the various protocols, please refer to the AOSC Buildbot Information.

Package Introduction and Maintenance

In principle, AOSC OS accepts and maintains all packages, unless one of the following applies:

The Builds

While building packages, the build environments must be controlled, updated, and minimal, where packages are only installed as required by the build-and-run-time dependencies.

Branch Merging

In the AOSC OS maintenance procedures, branch mergings are bi-directional.


With the branch and cycle descriptions specified above - as branch merging serves as the main mean of update introduction for the non-Proposal branches, there are certain limitations applied to the merging procedures.

Reversed Merging

Reversed merges, or stablestable-proposedtestingexplosive merges should be done periodically regardless of the cycle periods. However, during major merges, notifications will be made to prevent inconsistent merging.

The rckernel branch should also receive periodic reverse merging: stablestable-proposedrckernel.

Stable Update Testing

Updates for the stable branch, unless known to be involved with one or more 0-day security vulnerability(ies) or already broken in stable, are committed, built, and tested through the stable-proposed branches. stable-proposed updates are merged in the following procedure/schedule: