Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

0011: Qualify and deliver the same native archive

Status: accepted for 0.2.0 release delivery. Supersedes the development-only archive boundary in ADR 0010: Native Apple Silicon macOS. Published 0.1.0 support remains Linux-only until 0.2.0 is published. At that point this also supersedes the Linux-only scope of ADR 0007: Linux x86-64 first.

Decision

Build the Apple Silicon executable twice in separate clean target trees on macOS 15, using the pinned Rust compiler, remapped source paths and a macOS 15 deployment target. Require identical executable bytes, then package one copy with target-specific notices, its executable checksum and build provenance. This proves reproducibility within that hosted build; it does not promise identical output from different future hosted SDK images.

Freeze the resulting archive’s SHA-256 as an output of that workflow run. Install those exact bytes outside the source checkout on macOS 15 and 26. Run the applicable installed Command contract, Numerical profile fixtures, Spill, cleanup, signal and both corpus input modes before accepting it. The release uses this archive directly instead of rebuilding it after testing.

The Release workflow also requires Linux’s existing committed qualified checksums and package checks. Only after both platforms pass does it attest the archives and Linux packages and prepare a draft release. Download the draft’s macOS archive on both native versions, verify its release-workflow attestation and frozen hash, and repeat the installed checks. A failed delivery check leaves an unpublished draft for investigation. The maintainer publishes only after the complete workflow succeeds and the draft is reviewed.

Keep public download links and release metadata tied to site/release-version.txt, which names the published release. Candidate source versions and platform documentation can advance without pointing users at unavailable downloads. Update that file and published platform claims only when the corresponding release is available.

Considered options

  • Committing a future macOS executable hash would require rebuilding on a later hosted SDK image and assuming those bytes can be recreated. Reusing the tested archive avoids that assumption. Linux retains its controlled container build and committed qualification manifest.
  • Rebuilding the macOS archive for upload would break the binding between native installation evidence and delivered bytes.
  • Treating a CI artifact as published support would give users a download promise the latest release cannot yet meet.

Intel macOS, earlier macOS, native Windows and Apple notarization remain outside this platform scope. Hosted GNU comparisons retain their measured conditions; Linux performance claims do not become macOS claims.