Skip to main content

Release

The release version lives in the repository VERSION file. The native binary embeds that value, and Python wheel metadata reads the same source of truth.

Reploy uses Changie fragments for release notes. Before a final release, batch the unreleased fragments into CHANGELOG.md:

changie batch "$(tr -d '[:space:]' < VERSION)"
changie merge

Commit the updated CHANGELOG.md, the new .changes/<version>.md, and the removed unreleased fragments before publishing.

Dev releases do not consume fragments. Their GitHub Release notes include a raw list of the current unreleased fragments since the last final release.

Build release distributions locally:

tools/build_release_dists --clean

Publish from GitHub Actions after CI is green:

gh workflow run publish.yml --ref main --field version="$(tr -d '[:space:]' < VERSION)"

Pass the version from the selected ref's VERSION file, without a v prefix. The Actions run title includes this version, and the workflow checks that it matches the selected commit before starting CI and integration checks.

The workflow runs CI, integration checks, and release artifact preparation concurrently against the selected commit. All three must succeed before the publication job can request approval. Preparation uploads the wheels, binaries, checksums, and release notes as a release-<commit SHA> workflow artifact before requesting approval. Open the workflow run, inspect its commit and artifacts, and use Review deployments to approve the release environment. Rejecting the deployment leaves the artifacts unpublished. This approval is required for dev releases as well as final releases. After approval, the workflow publishes those same artifacts to PyPI and GitHub without rebuilding them.

Standalone integration runs retain the full portable-tool matrices and direct controlled-session contract. Publication runs perform those checks once in their mandatory CI gate, while integration still runs the representative cases and all other runtime checks.

macOS Docker integration installs checksum-pinned upstream binaries using tools/ci/install_macos_docker.py and tools/ci/macos-docker-tools.json, avoiding Homebrew source builds. Update the URLs and SHA256 values together when changing the tooling versions. The Intel Colima VM uses 3 CPUs and 8 GB of memory; other macOS hosts retain the 2-CPU/4-GB allocation. Smoke builds print their existing hierarchical profiles to help diagnose remaining preparation costs.

The repository's GitHub Settings > Environments > release environment must have required reviewers configured. Referencing an environment in the workflow does not itself require approval; GitHub enforces its protection rules outside the repository. Configure the release maintainer as a required reviewer, allow self-review if that maintainer also starts the workflow, and disable administrator bypass so publication requires the approval step.

The publish workflow reads VERSION, builds active Linux, macOS, and Windows wheels, publishes the wheel artifacts to PyPI, and creates a GitHub Release containing direct binary assets plus checksums:

  • reploy-linux-amd64
  • reploy-linux-arm64
  • reploy-darwin-amd64
  • reploy-darwin-arm64
  • reploy-windows-amd64.exe
  • reploy-windows-arm64.exe
  • SHA256SUMS

Initial macOS binaries may be unsigned and unnotarized. Developer ID signing and notarization are separate release-hardening work. Initial Windows binaries may be unsigned until Authenticode signing is added.

The PyPI project must be configured for GitHub trusted publishing for omry/reploy and .github/workflows/publish.yml. If the trusted publisher specifies an environment, it must match release.