The rc channel's Arch base can sit anywhere between stable's snapshot and
edge's, so a package built against stable's libraries is not necessarily
correct for rc. Copying stable's fast-ring artifacts into rc therefore shipped
possibly-mislinked packages to RC testers. Fast-ring packages now build
natively for all three channels, each in its own image against its own base
mirror, and the stable release's replication step is gone.
That required separating 'may be built here' from 'whose version wins'. The
release pair is now marked "pinned": its version is set per release on the rc
branch, so it builds for rc only from that branch's worktree
(OMARCHY_RC_PINS=1, set by omarchy-release rc) — master's shipped pins can
never overwrite an in-flight RC, even though check-versions now discovers rc
work like it does for edge and stable.
A package's .omarchy/package.json may now pin where it lives with
"channels": [...]. With the key present the package builds in each listed
channel except stable (stable is only fed by promotion); without it, today's
defaults hold (build for edge; fast-ring also builds stable directly).
package_moves_to_channel() is the advance/promote eligibility rule: a member
of the destination channel that is not built there natively.
The release pair (omarchy, omarchy-settings) is edge+rc+stable — edge stays
during the client-migration overlap window and drops later. The dev pair is
pinned to edge only.
Stable-track counterparts of the -dev packages. Source is pinned to a
single shared upstream commit with a real sha256 (pacman 7 validates
checksums on commit-pinned git sources), versioned per the attached-rcN
convention so vercmp orders rc1 < rc2 < final. Seeded at 4.0.0rc1 from
the quattro tip because no upstream 4.x tag exists yet and the packaging
requires the quattro tree (v3.8.x has no shell/ or etc/).
Both packages stay off the fast ring: RCs publish to edge only; stable
receives finals via bin/repo migrate.
Ryan Hughes