Releases use the same reviewed two-stage flow as DWB: a tag creates an unpublished Draft Release, and a human publishes that draft before artifacts are built and attached.
-
Choose a semantic version greater than the latest release.
-
Update the single machine-readable version owner in
package.json. -
Write
docs/releases/v<version>.mdand updateCHANGELOG.md. -
Run:
mise run test scripts/check-release.sh v<version>
-
Review and commit only the release changes, then create an annotated
v<version>tag. -
Push the commit and tag only after explicit publication approval.
-
The
draft-releaseworkflow creates an unpublished GitHub Release from the exact note. Review it and click Publish. -
The
releaseworkflow checks out the exact tag, verifies release identity, runsmise run testto build and exercisedist/git-hook-pure, confirms later package tests did not change those bytes, then usesscripts/prepare-release-assets.shto generate and verifySHA256SUMSand the exact two-file inventory before uploading those two assets with--clobber, so a manual retry is idempotent.
The npm package is also built from the same artifact. Its prepack lifecycle hook is a
thin adapter to the neutral mise run build task, so npm packaging still rebuilds
automatically without owning a separate build definition.
Publishing npm is intentionally separate from GitHub Release publication and is a
second explicit human action. Publish only from a clean checkout of the exact tag:
- Verify
HEADisrefs/tags/v<version>^{commit}and rerunmise run test. - Run
npm pack --dry-run, inspect the inventory, then runnpm packonce. - Publish that exact generated archive with
npm publish ./git-hook-pure-<version>.tgz --access public; do not runnpm publish ., which would repack mutable working-tree contents. - Verify
npm view git-hook-pure@<version> version dist.integrity, then exercise the pinnednpx git-hook-pure@<version> install-standalonecommand in a disposable Git repository before announcing the npm release.