[AksharP5]

Arch nightly packages currently sort above their corresponding stable release. Promotion therefore looks like a downgrade to package version comparison.

The builder uses an alphabetic prerelease suffix. It also keeps epoch=1, including in versioned cap provides, so corrected packages supersede the existing underscore-format packages. Retaining this upgrade path requires keeping the epoch on future packages; Arch's epoch rules make lower epochs older regardless of the upstream version.

Download filenames omit the epoch. For example, cap-bin-0.6.2-1-x86_64.pkg.tar.zst contains .PKGINFO version 1:0.6.2-1, which package version comparison uses.

Closes #2933

Same package inputs	Before	After
0.6.2-nightly.202610220300 vs 0.6.2	Nightly is newer	Stable is newer
Successive nightlies	Newer timestamp wins	Newer timestamp wins
Corrected package vs existing underscore package	Suffix correction alone would downgrade	Epoch preserves upgrade ordering

Verified with actual makepkg artifacts and native vercmp: eight scoped tests pass with zero skips. The regression fails on baseline 848d18fe7. Tests also check RC/numeric prereleases, epoch-free filenames, retained metadata epochs, versioned provides, and all three executable payloads. Shell/Node syntax, scoped Biome, workflow parsing and whitespace checks pass.

A focused CI workflow runs the native integration test as a nonroot user in Arch with Node, and rejects skipped tests. Local verification used synthetic executables and installed Arch tools; no packages were installed or uploaded and no live package repository was tested. Explicit manual installation remains possible. The fix applies to releases containing this script change.

Confidence Score: 5/5

The PR appears safe to merge; no actionable new issues were found.

Summary

This PR fixes Arch package ordering so stable releases sort above their nightlies.

• Arch stable releases now rank above matching prereleases.

Changes since the previous review add the filename rename, matching assertions, documentation, and a pinned checkout action. No actionable new issues were found. Tests were inspected, not run during this review.

_{Reviews (2) · Last reviewed commit: "chore(ci): pin checkout in Arch package ..." · Reviewed by Greptile}

[vercel]

@AksharP5 is attempting to deploy a commit to the Cap Software Inc Team on Vercel.

A member of the Team first needs to authorize it.

[richiemcilroy]

Thanks @AksharP5, great catch, and the native vercmp job is a really nice addition. The pre suffix ordering checks out against the alpm rules. One thing we want to settle before merging: with epoch=1, makepkg names the artifact cap-bin-1:0.6.2-1-x86_64.pkg.tar.zst. That colon ends up in the file we upload to CrabNebula in .github/workflows/desktop-release.yml and in the download filename users see. Could you rename the built package at the end of scripts/build-linux-arch-package.sh so the filename has no epoch (for example cap-bin-0.6.2-1-x86_64.pkg.tar.zst; pacman -U reads the version from .PKGINFO, not the filename), with a test assertion for it, and update the example in packaging/linux/README.md? We're also confirming on our side that we want to carry the epoch permanently, and we'll follow up here.

[superagent-security]

Superagent found 1 security concern(s).

[AksharP5]

@greptileai review

[AksharP5]

The requested filename change is in 38e8ad8. Packages are renamed without the epoch after makepkg, while .PKGINFO retains epoch=1; the README and integration assertion match. I rechecked the current head with native makepkg/vercmp: all eight packaging/configuration tests pass with zero skips. The checkout action is also pinned at 4753804. The permanent epoch decision remains with you.