This repository declares its release contract in
base_manifest.yaml. It is consumed by Base's guarded
release commands and is the source of truth for the version file, changelog,
GitHub Release, and Homebrew handoff.
The repository release line and its temporary publication gates are defined in
the versioning policy. Always enter the release workflow
through scripts/release; do not invoke
basectl release directly. The repository guard validates the candidate before
delegating safe operations to Base's generic release machinery.
-
Create or choose a release issue and set its repository Project metadata.
-
Create a release-preparation branch and dedicated worktree from
origin/main. -
Move the relevant
Unreleasedentries inCHANGELOG.mdinto a dated release section. UpdateVERSIONand the top release row inREADME.mdto the same version. Ordinary pull requests do not changeVERSION. -
Build the canonical release asset from the tagged commit and replace the
lib/bash/base-bash-libs.releasefields in that asset with the exact release version, tag commit,dirty_state=clean, andprovenance=release-artifact. The metadata is deliberately generated in the artifact rather than committed with a self-referential commit hash. -
Run the full library validation and inspect the diff:
./tests/validate.sh git diff --check
-
Open and merge the release-preparation pull request.
-
Sync local
main, then inspect the release from the repository root:scripts/release refs --version X.Y.Z scripts/release check --version X.Y.Z --manifest base_manifest.yaml scripts/release plan --version X.Y.Z --manifest base_manifest.yaml scripts/release notes --version X.Y.Z --manifest base_manifest.yaml scripts/release publish --version X.Y.Z --manifest base_manifest.yaml --dry-run
The
refspreflight is mandatory before any real publication attempt. It fails closed if the candidate tag exists locally or onorigin, or if either side cannot be inspected. -
Publish only after the readiness checks pass. Use
--yesonly from a trusted non-interactive release shell:scripts/release publish --version X.Y.Z --manifest base_manifest.yaml --yes
-
Verify the annotated
vX.Y.Ztag and the GitHub Release forbasefoundry/base-bash-libs.
The release contract requires the tap-owned formula
basefoundry/base/base-bash-libs in basefoundry/homebrew-base.
After the GitHub Release and its verified canonical source asset exist:
-
Create a tap release branch and update
Formula/base-bash-libs.rbto the canonical release-asset URL, version, SHA256, and version assertions in the formula test. Do not use GitHub's automaticarchive/refs/tags/...URL for v2. -
Validate the formula from the tap checkout:
brew install --build-from-source Formula/base-bash-libs.rb brew test basefoundry/base/base-bash-libs brew audit --new --formula Formula/base-bash-libs.rb -
Publish any tap bottle artifacts required by the tap policy, then open and merge the tap pull request.
-
Smoke-test a consumer install and verify that
BASE_BASH_LIBS_VERSIONand thebase-bashlauncher report the new version.
Base pins this repository by full commit SHA in its GitHub Actions workflows. After the release, update the Base pin to the release commit, run Base's source-checkout and integration tests, and record the dependency update in the Base changelog when it is user-visible or release-relevant.
Record the library release URL, asset checksums and provenance, Homebrew tap pull request, and Base dependency pull request on the release issue. Remove the release worktree and merged branches when safe. Do not publish a release while the worktree is dirty, the version metadata disagrees, the changelog section is missing, the repository release guard blocks the candidate, or a declared downstream handoff has not been completed or explicitly deferred.