release: 0.1.1 #116
Labels
No labels
blocked
blocker:ci-red
blocker:conflict
blocker:drill-pending
blocker:unrequested
bug
claimed
documentation
enhancement
epic
merge-next
needs-triage
ready
release
scope:apply
scope:capture
scope:coolify-api
scope:fleet
scope:manifest
scope:secrets
stale
state:addressing
state:bots-reviewing
state:building
state:needs-human
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: heavy-duty/cast#116
Loading…
Reference in a new issue
No description provided.
Delete branch "release/0.1.1"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The 0.1.1 release ceremony — merging this PR is the release
(CONTRIBUTING; #111, box#96's design).
The diff
package.json+package-lock.json:0.1.1-dev->0.1.1. Patch iscorrect — the shipped section carries only a
### Fixedentry.CHANGELOG.md:## Unreleasedstamped as## 0.1.1 — 2026-07-19,and re-armed with a fresh, empty
## Unreleasedimmediately aboveit. Both halves in this diff, per #113/#114 — stamping without
re-arming is what heavy-duty/rig#66 caught in the wild.
This is the first cast release to go through the merge door
0.1.0 could not. The interlock refused it (run 29698017907:
version '0.1.0' is bare, unchanged by this PR, and never released)because cast had said
0.1.0inpackage.jsonsince its first commit,so there was no
-devtransition to detect; 0.1.0 shipped by the manualtag fallback. main now genuinely reads
0.1.1-dev, so release.yml'sdecide step lands in the bare, changed state — the ceremony — and
proceeds.
Verification
npm run check— clean, 58 files.npm run build— tsc clean.npm test— 623 passed (35 files), matching main's baseline.test/release.test.ts— 41/41. The version-keyed guard added by #114is green on this exact tree: a bare version with an empty re-armed
## Unreleasedover the stamp is precisely the case it was written topermit.
bash .github/scripts/release-notes.sh 0.1.1 CHANGELOG.md— extractsnon-empty (3017 bytes), stops cleanly above
## 0.1.0.No change to
release.ymlwas needed. Thecast-0.1.1.tgzasset isbuilt and attached entirely by the workflow.
Verdict: Approve — I agree with this as-is.
Ceremony stamp at
ee9c832:package.json+package-lock.json:0.1.1-dev→ bare0.1.1CHANGELOG.md: empty## Unreleasedre-armed above## 0.1.1 — 2026-07-19with a populated### Fixedshipping section (the #113/#114 two-edit shape)Patch is correct for Fixed-only notes. First cast release that can actually take the merge door (real
-dev→ bare transition).releaselabel present; checks green (build, install, reconcile, scope). No blockers.Verdict: Approve. The 0.1.1 ceremony is complete, correct, and verified end-to-end on the exact head tree (
ee9c832). This is the first cast release able to take the merge door, and the decide step's asserts all land green when simulated against this tree.Ceremony vs CONTRIBUTING.md#releasing (at this head)
package.json:4andpackage-lock.json:3/package-lock.json:8:0.1.1-dev-> bare0.1.1, both lockfile spots in step. Patch bump is right — the shipping section is### Fixedonly.CHANGELOG.md:8re-armed empty## Unreleasedimmediately aboveCHANGELOG.md:10## 0.1.1 — 2026-07-19(date is correct). Both halves of the #113/#114 two-edit shape are in this one diff, exactly what CONTRIBUTING step 1 mandates.Full suite on the stamped tree (run locally at
ee9c832)npm run build— tsc clean.npm test— 623 passed, 35 files (matches the PR body's claim and main's baseline).test/release.test.tsin isolation — 41/41, including #114's version-keyed guard: bare version + empty re-armed## Unreleasedover the stamp is precisely the state it permits, and it is green here — this is the state that #108 proved must not be red.npm run check— biome clean, 58 files.bash .github/scripts/release-notes.sh 0.1.1 CHANGELOG.md— extracts 3017 bytes non-empty, starts at### Fixed, stops cleanly above## 0.1.0.Merge-door simulation (
.github/workflows/release.yml)Walked the decide step's logic against this tree and origin/main:
ver=0.1.1(bare),base=0.1.1-dev(origin/mainaa5905d, the merge base) — the bare, changed state: the ceremony branch, proceeds. This is the real-devtransition 0.1.0 never had (run 29698017907 refused it correctly; 0.1.0 shipped via the manual tag fallback).releaselabel is present on #116, socommits/<merge_sha>/pullswill find a merged, release-labeled PR behind the push.git ls-remote origin refs/tags/0.1.1— empty;gh release view 0.1.1— not found. Nothing exists yet; the tag create and publish will proceed. (The 0.1.0 release exists with bare tag0.1.0, confirming the no-vscheme the workflow tags with.)0.1.2-devand re-arm main's version; the changelog re-arm is already in this diff, so the two halves meet astest/release.test.tsexpects.CHANGELOG completeness since the
0.1.0tag (f098a27)Merged since the tag: #114 (the changelog re-arm fix, #113) and #115 (the
0.1.1-devbump). #114 is the sole### Fixedentry in the 0.1.1 section — complete. #115 is version machinery with no user-facing surface, correctly omitted. #112 predates the tag and already lives in the 0.1.0 section. Nothing missing, nothing misplaced.Version consistency
0.1.1lives in exactly the three stamped files. The0.1.0strings inREADME.md:30andinstall.sh:135/install.sh:147are pre-existing prose/examples about the first release, not version pins this ceremony owns — no action needed here (a follow-up could refresh the README's transitional note now that releases exist, but that is not this PR's job).CI on the head is green (build, install, reconcile, scope). No changes requested — merge is the ship decision.
— automated review by
claude-bot-andresmgsl· heavy-duty-review-botVerdict: I agree with everything and have no additional feedback.
The current head correctly performs the complete 0.1.1 release ceremony: both package manifests move from 0.1.1-dev to 0.1.1, and CHANGELOG.md preserves an empty Unreleased section above the populated 0.1.1 stamp. The release label is present, the version transition and changelog structure match the repository release guidance, and all current check runs are successful.