Release Process
SicarioSpec releases are GitHub releases backed by signed-off local validation, tag-driven packaging, full Spec Kit bundle assets, install-allowed catalogs, and GitHub artifact attestations for built distributions.
Versioning
- Package version is stored in
VERSION,pyproject.toml, andsicario_cli/version.py. - Preset, extension, and starter control-map versions should match the release unless they intentionally carry their own schema version.
- Release tags use
vMAJOR.MINOR.PATCH, for examplev0.1.0. - Release tags are immutable once published. Do not move or delete a published tag; ship a new patch release instead.
- Release assets are classified as
publiconly after validation confirms they contain no secrets, private evidence, customer data, tenant identifiers, or unpublished vulnerability details.
During the 0.x line, breaking changes may ship in minor versions. Patch
versions should be bug fixes, documentation fixes, or non-breaking hardening.
Pre-Release Checklist
Run from the repository root:
python3 -m unittest discover -s tests
python3 -m sicario_cli.cli verify .
python3 -m sicario_cli.cli verify . --validate-rules
python3 scripts/build_release_assets.py
tmpdir=$(mktemp -d)
python3 -m pip wheel . -w "$tmpdir/wheelhouse"
python3 -m venv "$tmpdir/venv"
"$tmpdir/venv/bin/pip" install "$tmpdir"/wheelhouse/sicario_spec-*.whl
"$tmpdir/venv/bin/sicario" --version
"$tmpdir/venv/bin/sicario" init "$tmpdir/project" --profile appsec,cloud-iac,security-toolchain,compliance
"$tmpdir/venv/bin/sicario" verify "$tmpdir/project"
Confirm:
CHANGELOG.mdhas an entry for the release.presets/sicario-core/CHANGELOG.mdhas an entry for the release when the catalog preset changes.README.mdinstall and badge links are accurate.presets/sicario-core/README.mdcatalog install instructions point to the release preset ZIP asset.catalogs/presets.json,catalogs/extensions.json, andcatalogs/bundles.jsonpoint to the intended release ZIP assets.bundle.ymlpinssicario-speccomponents to the release version and keepssicario-coreas the lower-priority base layer under appended profile overlays.docs/governance/data-classification.mdanddocs/governance/tagging-taxonomy.mdare current.- Release notes and assets follow classification and tagging discipline.
- Git working tree is clean.
- GitHub Actions are green for the release commit.
- No generated output, local build output, secrets, or private evidence files are staged.
GitHub Release
version="$(cat VERSION)"
git tag -a "v$version" -m "SicarioSpec v$version"
git push origin main "v$version"
The release workflow runs on the pushed tag. It verifies the tag against
VERSION, pyproject.toml, and sicario_cli/version.py, builds the sdist,
wheel, all 11 preset ZIPs, sicario-guard-$version.zip,
sicario-spec-$version.zip, and the three catalog JSON files. It then validates
the release asset set, smoke-tests native specify bundle install sicario-spec
against localhost catalogs, smoke-tests the wheel, emits artifact attestations,
and creates the GitHub release with assets when the release does not already
exist.
Existing GitHub releases are treated as immutable. A rerun for an existing tag will rebuild, smoke-test, upload the workflow artifact, and emit attestations, but it will not add, delete, replace, or rename release assets. Ship a new patch release if published assets need to change.
If the GitHub release does not already exist, the workflow creates it with generated release notes. To curate release notes before packaging, create a draft or published release for the tag first, then push the tag or run the workflow manually for that tag.
Curated release notes should include:
- What's included.
- Bundle install commands and CLI install command.
- Validation performed.
- Known limitations.
Bundle Asset Smoke Test
Use this local smoke when bundle manifests, catalogs, release packaging, or Spec Kit compatibility changes:
smoke_assets="$(mktemp -d)"
python3 scripts/build_release_assets.py \
--output-dir "$smoke_assets" \
--catalog-dir "$smoke_assets/catalogs" \
--catalog-base-url "http://127.0.0.1:8766"
python3 -m http.server 8766 --bind 127.0.0.1 --directory "$smoke_assets" &
server_pid="$!"
trap 'kill "$server_pid"' EXIT
SPECIFY_BIN=specify scripts/smoke_bundle_install.sh http://127.0.0.1:8766/catalogs
The smoke checks that a fresh Spec Kit project can add the Sicario preset,
extension, and bundle catalogs; install sicario-spec; record all 12 bundle
components; preserve expected preset priorities; install sicario-guard; and
resolve a composed spec-template chain.
Post-Release
- Confirm the GitHub release is public.
- Confirm the release badge resolves.
- Confirm OpenSSF Scorecard has a recent result after the workflow runs.
- Keep the OpenSSF Best Practices badge status honest; do not display an achievement badge until the project has completed the external self-assessment.
PyPI Publishing
PyPI publication is intentionally separated from the GitHub release workflow.
The publish-pypi workflow is manual, uses PyPI Trusted Publishing through
GitHub's OIDC token, and requires the pypi GitHub environment.
Before the first publish:
- Reserve or create the
sicario-specPyPI project. - Configure a PyPI Trusted Publisher for owner
dfirs1car1o, repositorysicario-spec, workflow.github/workflows/publish-pypi.yml, environmentpypi. - Configure the
pypiGitHub environment with required reviewers. - Confirm the GitHub release assets and attestations for the same tag already exist.
To publish:
- Open Actions -> publish-pypi -> Run workflow.
- Enter the release tag, for example
v0.5.1. - Enter
publishin the confirmation field. - Approve the
pypienvironment gate. - Confirm the PyPI release page, package hashes, and install command.
Do not use long-lived PyPI API tokens for this repository. If trusted publishing is unavailable, defer PyPI publication until it can be configured.