release: 0.2.0 #69
Labels
No labels
attention
blocked
blocker:ci-red
blocker:conflict
blocker:drill-pending
blocker:unrequested
bug
claimed
documentation
enhancement
epic
merge-next
needs-ruling
needs-triage
offsite
post-merge
ready
release
scope:bootstrap
scope:coolify
scope:db
scope:docs
scope:drill
scope:installer
scope:labels
scope:platform
scope:runner
scope:users
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/rig#69
Loading…
Reference in a new issue
No description provided.
Delete branch "release/0.2.0"
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 ceremony PR for 0.2.0. Merging it is the release (CONTRIBUTING §Releases; #47).
Two files, three lines:
VERSION:0.1.1-dev->0.2.0CHANGELOG.md:## Unreleasedstamped as## 0.2.0 — 2026-07-19, and a fresh empty## Unreleasedput back immediately above it (#66's re-arm — the second edit is the whole point, and no workflow does it for you).Why minor, not patch
The shipped section carries an explicit
### Changed/ BREAKING:rig bootstraptakes the users file, and requires it (#51) next to an### Added(#49).0.1.1would have misrepresented a documented breaking change, so the version is0.2.0by operator decision rather than a straight de-devof the current value.Verification
bash test/cli.sh— 400 passed, 0 failedbash test/release.sh— 68 passed, 0 failed, includingCHANGELOG.md: armed for the VERSION it carries (#66)against this treeshellcheck -xover CI's exact sweep (bin/* **/*.sh, globstar) — 22 files, cleanrelease.ymlsources (changelog_section CHANGELOG.md "$(cat VERSION)") — 9450 bytes, stops cleanly before## 0.1.0, BREAKING entry present and legibleThis is the first ceremony to exercise #67's
changelog_armedguard for real, and the re-armed tree is exactly the case it was written to permit: bareVERSION, empty## Unreleasedon top. It passes.Merge-door interlock
release-on-merge's decide step readsbase_ver=0.1.1-dev->ver=0.2.0: non--devand changed by this PR, so it takes thebare, changed → the ceremony: proceedbranch and then confirms thereleaselabel off the merge commit. cast's first-release refusal was thebare, unchanged, never releasedbranch — reachable only without a-devpredecessor, which rig has.Do not merge this without danmt — merging is the release.
Approve. Ceremony-only diff, correct shape per CONTRIBUTING §Releasing at this head, and every gate it will hit was re-verified on the exact PR tree (
0ea1933).Ceremony shape
VERSION:1—0.1.1-dev->0.2.0. Bare, nov, matches the tag scheme.CHANGELOG.md:7-9— the two-line insertion does both mandated edits at once: the pre-existing## Unreleasedheading is left standing (now empty — the re-arm, #66/#67's mandated shape) and## 0.2.0 — 2026-07-19is stamped immediately below it, over today's date. Exactly CONTRIBUTING.md:52-66.### Changed/ BREAKING for #51 (CHANGELOG.md:33), which0.1.1would have misrepresented.Verified on this tree (not taken from the PR body)
bash test/cli.sh— 400 passed, 0 failed.bash test/release.sh— 68 passed, 0 failed, includingCHANGELOG.md: armed for the VERSION it carries (#66)(test/release.sh:145-146) against the real stamped tree — the first live exercise of #67's VERSION-keyed guard, and it passes in the bare-VERSION + empty-Unreleased state it was written to permit.shellcheck -xover CI's globstar sweep — clean.changelog_section CHANGELOG.md 0.2.0(the same.github/scripts/release-lib.shthe workflow sources) — 9,506 bytes, non-empty, starts at### Added, stops cleanly before## 0.1.0, BREAKING migration text intact.Merge-door simulation (.github/workflows/release.yml:123-193)
base_verat origin/main (fcbe363, this PR's exact base) is0.1.1-dev, mergedver=0.2.0— non--devand changed, so it takes thebare, changed -> the ceremony: proceedbranch (release.yml:122).releaselabel, so the merged-PR label read behind the merge commit will answer true.refs/tags/0.2.0on origin and no0.2.0release exists (gh release listshows only0.1.0) — nothing to collide with.0.2.1-devcorrectly from the awk at release.yml:222.CHANGELOG completeness
Exactly six PRs merged since the
0.1.0tag (6ff90f0, 18:03Z — PR #48 merged 17:12Z, before the tag, so the merge-door feature correctly lives in 0.1.0's section): #53, #54, #55, #59, #60, #67. All six are represented in the 0.2.0 section by their issues — #49 (CHANGELOG.md:13), #51 BREAKING (CHANGELOG.md:33), #50 (CHANGELOG.md:124), #57 (CHANGELOG.md:143), #58 (CHANGELOG.md:105), #67 (CHANGELOG.md:71). The only other commits since the tag are the workflow's own-devbump (5a30c72) and intra-PR commits. Nothing smuggled: the diff is 2 files / 3 lines, ceremony-only.Version consistency
bin/rig:9reads theVERSIONfile at runtime — no hardcoded string to drift. README references0.1.0only as a pin example and in pre-existing "until 0.1.0 is cut" transitional notes (README.md:27,34-38,425) — those were already stale on main before this PR and are correctly out of scope for a ceremony diff. Non-blocking nit: a follow-up docs PR could retire the two transitional callouts now that the release channel resolves.Merging this is the release — over to danmt for the ship decision.
— automated review by
claude-bot-andresmgsl· heavy-duty-review-botVerdict: Approve — I agree with this as-is.
Ceremony
VERSION0.1.1-dev→0.2.0; CHANGELOG re-arm shape is correct — empty## Unreleasedleft on top,## 0.2.0 — 2026-07-19stamped immediately below so prior Unreleased body becomes the 0.2.0 section (#66/#67).--usersentry (#51) in the stamped section.release; merge-door interlock (bare + changed from-dev) is the happy path #47 designed.Checked
changelog_armedand notes extraction succeed on this exact tree is consistent with the design.Merging is the release — operator-gated as noted.
No blockers.
Verdict: I agree with everything and have no additional feedback. The ceremony diff correctly re-arms CHANGELOG.md, the breaking bootstrap change supports 0.2.0, the stamped section and VERSION transition agree, all current checks pass, and no 0.2.0 tag or release exists.