Back to blog

Release

Tag-based publishing with slimmer release verification

Ink/charcoal doodle: a release tag passes through a verification shield into a checked package record.

InvarLock 0.7.2 simplifies the public release surface around immutable source tags plus the PyPI wheel and sdist, with docs and verification gates aligned around that path.

2 min read
InvarLock Team

Release: InvarLock 0.7.2 - Tag-based publishing, leaner release verification, and repo hardening

Highlights

  • Tagged releases now treat the immutable vX.Y.Z source tag plus the PyPI wheel and sdist as the canonical public release surface, replacing the earlier emphasis on GitHub release-page bundles.
  • Release-verification and security docs now center on resolving the tag, checking PyPI metadata and hashes, and smoke-testing the published wheel in a fresh environment.
  • Under the hood, 0.7.2 also tightens the repo surface with owner-aligned test buckets, refreshed security-sensitive pins, stronger GPT-2 and gitleaks workflow coverage, and cleanup for code-scanning and ruff findings in helper paths.

0.7.2 is mostly a release-surface cleanup. The public command set is not being widened here; instead, the release workflow and docs are being narrowed to the surfaces downstream consumers actually depend on. The synced release-verification pages now treat the tag, wheel, and source distribution as the primary audit objects, with the workflow rebuilding from the resolved tag commit and recording the maintainer-only provenance and SBOM evidence around that path.

That shift also simplifies the contract story. The contract docs now describe the canonical public contract data as something that ships inside installed wheels and source tags, while detached contract bundles move into maintainer-built helper territory instead of the default public release narrative. For site readers, that makes the boundary clearer: verify the published package and tag directly, and treat the heavier release-workflow artifacts as a deeper maintainer trail rather than the first thing every consumer needs.

The patch release also keeps hardening the repo behind the published surface. The upstream changelog pairs the publishing cleanup with a large test-tree refactor, refreshed security-sensitive pins, stronger scheduled GPT-2 and gitleaks coverage, and fixes for code-scanning and ruff findings in helper scripts. If you maintain internal release-verification checklists or wrappers around the published package, this is the release to re-check against the current docs and release flow.

For the immutable release record, read the tagged CHANGELOG.md for v0.7.2.

More from the blog

Continue through recent releases and implementation notes.