docs(changelog): one line per entry, and a pass over the whole file #147
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:cli
scope:drill
scope:host
scope:installer
scope:templates
scope:tiers
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/box#147
Loading…
Reference in a new issue
No description provided.
Delete branch "docs/changelog-one-line"
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?
A house rule, and the pass that makes the file obey it.
The rule: every changelog entry is one line. Say what changed, cite the
issue, stop. The reasoning — why it was wrong, how it was found, what it cost,
what it implies — belongs in the PR body and the commit message, which is where
anyone chasing it already goes.
CHANGELOG.mdanswers one question: what isdifferent in this version.
Documented as a new
## Changelog entriessection in CONTRIBUTING.md, directlyabove
## Releases.The pass
CHANGELOG.md: 1302 lines → 180. Every entry in every section, includingthe shipped ones.
Before:
After:
What was preserved, and how it was checked
The mechanical risks here are heading loss and entry loss. Both are asserted,
not eyeballed:
##heading added, removed, altered or reorderedgit diff origin/main -- CHANGELOG.md | grep -E '^[-+]## 'grep -c '^- 'before/afterrelease-notes.sh0.8.0 / 0.7.0 / 0.6.0 / 0.5.0That first row is the load-bearing one —
changelog-monotonic.shfails thebuild if a
## X.Y.Zheading disappears, andrelease-notes.shextracts byexact heading match, so the published release bodies depend on those lines
surviving verbatim. They do.
Subheading grouping (
### Added/### Changed/### Fixed) and entry orderare preserved. No section had duplicate subheadings to merge.
Two judgement calls
BREAKING:marker was added that the file did not have — on the#123 template rename (
claude→claude-box, …). The entry's own text saysrig's roles are a hard cut with no aliases and that a pre-rename spelling
produces a failed mint, which is breaking by any reading; rig marks the same
change the same way. The 0.5.0 debrand was deliberately not marked,
because that section's intro explicitly promises everything legacy-facing is
honored forever.
(#141)survives; theheavy-duty/rig#97cited three paragraphs into itsbody does not. The linked issue carries the rest — that is the point of
citing it.
Consequence worth stating
The GitHub release bodies already published for 0.8.0 / 0.7.0 / 0.6.0 / 0.5.0
were generated from the old prose, so they no longer match this file. Re-pushing
them from the rewritten sections is queued as a follow-up once this lands.
Verdict: Approve — I agree with this as-is.
Why
CONTRIBUTING.mddocuments one-line entries above## Releases.##heading churn; 73→75 bullets (+ stacked #146 fix + the rule); subheading groups and entry order preserved; shipped 0.8.0…0.5.0 still extract; CI green including rehearsal.BREAKING:on the #123 template rename is justified (hard cut, no aliases — matches rig). 0.5.0 debrand correctly left unmarked.@
683217e✅ Approved — I agree with all of this, no concerns.
I re-ran the invariants independently from the diff rather than trusting the table: zero
##heading lines added or removed, zero###subheading lines touched, and entry lines go 73 → 75 — exactly the stacked #146 entry plus the rule's own. The rewritten one-liners I sampled are faithful (surface-first, headline refs kept) and the addedBREAKING:on the #123 template rename is right by the entry's own text — a failed mint on the old spelling is breaking, and it matches rig's treatment of the same change. The CONTRIBUTING## Changelog entriessection is the rule stated once with a good/bad pair, which is all it needs. Thetest/release.shhunk is #146, already reviewed there. Re-pushing the shipped release bodies as a follow-up is the right sequencing.— automated review by
claude-bot-andresmgsl· heavy-duty-review-botVerdict: I agree with everything and have no additional feedback. The full pass preserves release headings and entry count, accurately marks the hard template rename as breaking, and the stacked functional fix and all current checks are acceptable.
@danmt — round 1 closed, all three bots approving with no changes requested. Handing this over.
What it does
Adopts the one-line changelog rule (your call this cycle), documents it in
CONTRIBUTING.mdas## Changelog entriesabove## Releases, and applies the full pass:CHANGELOG.md1302 lines → 180, every entry in every section including the shipped ones.The rule: say what changed, cite the issue, stop. Rationale lives in the PR body and commit message.
Round history
One round, three approvals, zero changes requested, no nits:
grok-bot-andresmgslBREAKING:on #123 justified; 0.5.0 debrand correctly left unmarkedclaude-bot-andresmgsl##lines touched, 73 → 75 entriescodex-bot-andresmgslVerification
The two destructive risks are asserted, not eyeballed:
##heading added/removed/altered/reorderedgit diff origin/main -- CHANGELOG.md | grep -E '^[-+]## 'grep -c '^- 'release-notes.sh0.8.0 / 0.7.0 / 0.6.0 / 0.5.0That first row is load-bearing —
changelog-monotonic.shfails the build if a## X.Y.Zheading disappears, andrelease-notes.shextracts published release bodies by exact heading match.Payoff: box's 0.9.0 section now extracts 45 lines where the old prose would have published 580.
Two things for your judgement
BREAKING:marker the file never had — on the #123 template rename (claude→claude-box). The entry's own text calls it a hard cut with no aliases where a pre-rename spelling produces a failed mint, and rig marks the same change the same way. Both bots that commented on it agreed, but it is me adding a claim the source did not make, so it is yours to veto — one line to revert. I deliberately did not mark the 0.5.0 debrand, because that section's intro explicitly promises everything legacy-facing is honored forever.(#141)survives; aheavy-duty/rig#97cited three paragraphs into a body does not.Consequence, queued as follow-up
The GitHub release bodies already published for 0.8.0 / 0.7.0 / 0.6.0 / 0.5.0 were generated from the old prose and no longer match this file. Re-pushing them from the rewritten sections is queued once this lands — flagging so it is a decision you have seen, not a surprise.
Ordering
#146 fix→#147 (this)→#148 release: 0.9.0. Sits on #146; wants to land second.