## Why
Publishing a hotfix for an older release line or alpha can replace a newer prerelease pointer. Release pointers should advance according to version order.
## What changed
- Share release version validation and numeric comparison across publishing scripts, including alpha hotfix suffixes and alpha, beta, and stable ordering.
- Read the prerelease pointer directly from R2 and update it only for a newer version or missing or invalid version metadata.
- Restrict `latest-alpha-cli` updates to alpha releases with successful R2 and npm publishing, and compare against the branch's Cargo version before advancing it. Allow replacement when the manifest version cannot be parsed or validated.
## Testing
Add 15 passing unit tests covering version validation, older release lines and alphas, numeric hotfix ordering, prerelease precedence, equal versions, and missing or invalid versions.
GitOrigin-RevId: 6bee3906a47f613b662ef2b2224cfcbd1b56650c
## Why
R2 publication waited for DotSlash to finish before uploading any release
assets, extending the release pipeline's critical path.
## What changed
- Start an `assets` stage after the GitHub release is created, in parallel with
DotSlash publication. Upload available assets concurrently without publishing
release metadata or channel aliases.
- Run a `finalize` stage after both jobs complete. Verify assets already present
in R2, upload any assets DotSlash added, and then publish metadata, stable
installer aliases, and release channels.
- Validate downloaded assets before upload and retain no-overwrite semantics
across both stages.
GitOrigin-RevId: 1c3e8ca715be4064c2532a5c651f1bbe03ed96a4
## Why
The Rust release workflow accepts alpha versions with a second numeric suffix,
such as `1.2.3-alpha.4.1`, but the R2 publisher rejects them as invalid.
## What changed
- Allow up to two numeric suffix components for alpha versions in
`publish_r2_release.py`.
- Document that its version pattern must remain aligned with release tag
validation in `rust-release.yml`.
GitOrigin-RevId: 8df68ce4f4d3e652367f7394a642827f21979d70
## What changed
- Publish `install.sh` and `install.ps1` from stable release assets to the
mutable `codex/install.sh` and `codex/install.ps1` R2 keys.
- Require both installer assets and verify each uploaded object's size,
SHA-256 metadata, and CRC64 checksum before completing publication.
- Leave prerelease publication unchanged.
GitOrigin-RevId: 869f5fcd6c5f5d7fa4dc39c5216b31409d595fc9
## What changed
- Publish the verified `release.json` metadata to `codex/channels/latest` for
stable releases and `codex/channels/prerelease` for prereleases.
- Pass the release classification through the reusable R2 workflow so GitHub
Releases and R2 channels use the same stable-versus-prerelease decision.
- Allow channel objects to be replaced while keeping versioned release objects
immutable, and verify each channel upload before completing the publication.
GitOrigin-RevId: bd5c728c5565befe42b041ee1a032b111daca1c2
## What changed
- Add a reusable workflow that runs after the GitHub Release and DotSlash publishing jobs and mirrors each release asset to a versioned R2 prefix.
- Validate GitHub asset sizes and SHA-256 digests before upload, publish objects without overwriting existing files, and verify their remote size, digest metadata, and CRC64 checksum.
- Generate `release.json` with installer-facing asset URLs and digests, then publish and verify it alongside the release assets.
- Allow an in-progress Rust release workflow to finish instead of cancelling it when another run starts.
GitOrigin-RevId: e6717cd27914994accced6e2c5df696f0e9a558e
Ian MacLeod