Not a bug (see #17, closed as misdiagnosed) — a docs gap that cost real time when releasing bounded-systems/repo-health for the first time.
Two things worth documenting
1. Bootstrapping a first release
mint release tags the current manifest version (reads deno.json/jsr.json/package.json + the CHANGELOG entry) — it does not need .release/ intents (that's mint version). So a brand-new repo's first release works two ways, and neither is obvious from the README:
- Hand-seed: set the initial version in the manifest + write the first CHANGELOG entry, then
mint release.
- Intent path: add one
bump: minor intent, mint version (→ 0.1.0 + CHANGELOG + consumes it), then mint release.
A short "First release" section in the README / .release/README.md would save the next person the mint version vs mint release confusion.
2. mint release needs a tag-creation-permitted actor under restricted orgs
mint release cuts the tag locally and then git push <remote> <tag> (release.mjs path). Under an org/enterprise ruleset that restricts tag creation, that push is rejected — even for an admin:
! [remote rejected] v0.1.0 -> v0.1.0 (Cannot create ref due to creations being restricted)
The release then can't produce its GitHub-side artifacts (release/binaries/provenance key off the v* tag via release.yml). Worth a README note that adopters must wire a ruleset bypass actor (a release App/bot or release/* identity) permitted to create v* tags before their first release — and, if feasible, a --no-push + "push via the release actor" recipe so the tag push carries a bypass identity. (Real-world trigger: repo-health's v0.1.0 push is blocked by an enterprise tag-creation rule; the package shipped to JSR via CI anyway.)
Not a bug (see #17, closed as misdiagnosed) — a docs gap that cost real time when releasing
bounded-systems/repo-healthfor the first time.Two things worth documenting
1. Bootstrapping a first release
mint releasetags the current manifest version (readsdeno.json/jsr.json/package.json+ the CHANGELOG entry) — it does not need.release/intents (that'smint version). So a brand-new repo's first release works two ways, and neither is obvious from the README:mint release.bump: minorintent,mint version(→ 0.1.0 + CHANGELOG + consumes it), thenmint release.A short "First release" section in the README /
.release/README.mdwould save the next person themint versionvsmint releaseconfusion.2.
mint releaseneeds a tag-creation-permitted actor under restricted orgsmint releasecuts the tag locally and thengit push <remote> <tag>(release.mjs path). Under an org/enterprise ruleset that restricts tag creation, that push is rejected — even for an admin:The release then can't produce its GitHub-side artifacts (release/binaries/provenance key off the
v*tag viarelease.yml). Worth a README note that adopters must wire a ruleset bypass actor (a release App/bot orrelease/*identity) permitted to createv*tags before their first release — and, if feasible, a--no-push+ "push via the release actor" recipe so the tag push carries a bypass identity. (Real-world trigger: repo-health'sv0.1.0push is blocked by an enterprise tag-creation rule; the package shipped to JSR via CI anyway.)