Release

New Bloom Release

Model (important — read before acting)

Bloom is a library, not a CLI. It's consumed by games as "bloom": "file:../../" or (eventually) via npm. The release event therefore is:

1. The version in package.json is the version to ship.
2. Tag HEAD (or the commit that bumped the version) with vX.Y.Z.
3. Push the tag. This fires .github/workflows/release.yml, which gates on the Tests workflow passing for the same SHA and then creates the GitHub Release.
4. Watch both workflows. Report success or failure.

Unlike Perry, Bloom does not bump the patch version on every commit. The version in package.json is bumped explicitly at release time. /release can do the bump for you if you pass patch / minor / major, or you can bump it in a regular commit first and just run /release to tag HEAD.

Steps

1. Sanity checks

• git status — must be clean (unless we're about to do a patch/minor/major bump, in which case a dirty package.json alone is acceptable only if you are the one about to edit it).
• git rev-parse --abbrev-ref HEAD — must be main. If not, STOP and ask.
• git fetch origin && git log HEAD..origin/main --oneline — must be empty. If origin is ahead, pull first.

2. Determine the target version

• Read package.json version field.
• If $ARGUMENTS is patch / minor / major:
  • Compute the new version.
  • Edit package.json.
  • git add package.json && git commit -m "chore(release): vX.Y.Z".
• Otherwise the current package.json version is the release version. Do not bump.

3. Verify the tag doesn't exist

git rev-parse "vX.Y.Z" 2>/dev/null && echo "tag exists — aborting" && exit 1
git ls-remote --tags origin "vX.Y.Z" | grep -q "vX.Y.Z" && echo "tag exists on origin — aborting" && exit 1

If the tag already exists locally or on origin, STOP. Either the release already shipped or someone started it and didn't finish — don't silently duplicate. Retagging a published version is a cardinal sin.

4. Survey commits since the last tag

last_tag=$(git describe --tags --abbrev=0 2>/dev/null || echo "")
if [ -n "$last_tag" ]; then
  git log "$last_tag"..HEAD --oneline
else
  git log --oneline -20   # first release — no previous tag
fi

Group the subjects mentally by feat: / fix: / perf: / docs: / chore:. These become the "Highlights / Features / Fixes" sections in the release body.

5. Push the bump commit (if any) + tag

# If step 2 created a bump commit:
git push origin main

git tag "vX.Y.Z"
git push origin "vX.Y.Z"

The tag push fires two workflows in parallel:

• test.yml — full CI matrix (macOS / Linux / Windows builds, shared-crate tests, WASM build)
• release.yml — its await-tests job polls for the test.yml run on the same SHA and gates the release on it

6. Create the GitHub Release

gh release create "vX.Y.Z" \
  --title "vX.Y.Z" \
  --notes "$(cat <<'EOF'
## Highlights
- ...

## Features
- ...

## Fixes
- ...

## Infrastructure
- ...
EOF
)"

If $ARGUMENTS contained free-text highlights (anything other than the patch/minor/major keywords), seed the "Highlights" section from it.

If you skip the gh release create step, release.yml's github-release job will auto-create a release with --generate-notes once the gate passes. The explicit-body path is preferred when there's narrative worth writing; the auto-notes fallback keeps the release from just not existing if something goes sideways.