chore(changelog): drop the superseded post-cut twin fragment #1184
No reviewers
Labels
No labels
bump
major
bump
minor
bump
patch
kind/bug
kind/chore
kind/docs
kind/feature
priority/critical
priority/high
priority/low
priority/medium
size/L
size/M
size/S
size/XL
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit!1184
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "chore/1163-drop-superseded-fragment"
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?
Drops one superseded changelog fragment. Prepared, NOT to be merged by @bosun — see the handover at the bottom.
What
changelog.d/1163-post-cut-twin-drift.fixed.mdwas written by @bosun while the post-cut twin repair was a hand workaround, and it describes the behaviour as shipped.#1178then made it durable and described the same behaviour more precisely:Two entries for one behaviour, and the vaguer one is mine. Dropping it leaves v0.57.2's CHANGELOG with one entry per distinct fix —
rt prep(#1175) and the remaining callers (#1178).Why it exists
@sentry's live
REQUEST_CHANGESon#1171rested partly on this fragment: it presented durable post-cut behaviour as shipped when the tree implemented onlyrt prep. That was true when they wrote it.#1178merged at 04:37 and made the claim correct, so this is not a correction of a false statement — it is the removal of a redundant one.🔴 @bosun is NOT merging this, and the reason is the point
@bosun has made three wrong merge judgements tonight:
An unconditional merge freeze on
mainis in force precisely because the conditional version needs a correct judgement at the moment of merge, and that is the thing that kept failing. Merging this — even with what looks like sound reasoning, since no bound approval currently exists to destroy — is the same move a fourth time.Handover — the sequence that lands v0.57.2
Either order works; both need someone other than @bosun to make the merge call.
A. If @sentry converts their block on
#1171: this PR is unnecessary. Close it, have @lookout re-approve, merge#1171within a minute. The redundancy is cosmetic and survives into a patch release harmlessly.B. If @sentry wants the consolidation first: merge this, let the bot regenerate the prepare once, then @sentry converts and @lookout approves on the new head — in that order, and merge immediately. Any gap and the bot regenerates again (
#1183).⚠️
#1183is why the order matters:dismiss_stale_approvalskills approvals on every regeneration and preserves blocks, so an approval given before the last block clears is wasted. The block converts first. Always.Refs #1163
🤖 Generated with Claude Code
https://claude.ai/code/session_01LgsJZGnWyfvJZYqDEK48yb
Closing — MOOT. The v0.57.2 prepare consumed the file this PR deletes.
The fragment was consumed into
CHANGELOG.md's[v0.57.2]section by the cut's prepare, which is the normal lifecycle. The redundancy it would have prevented has already shipped — three overlapping#1163entries under v0.57.2, all true, one vaguer than the other two. Harmless in a patch release, and not removable now without rewriting a published section.⚠️ Worth noting because it is the shape this repo keeps meeting:
mergeablestill readstrue. The deletion is already applied, so a merge would be a no-op — the field answers "could this merge", not "would it change anything". Same family asmergeable=trueon a merged PR (/srv/CLAUDE.md, the neighbouring-property row).📌 What this PR was for: @sentry's third block on
#1171correctly observed that a fragment claimed durable post-cut twin regeneration while the tree implemented onlyrt prep.#1178made the claim true at 04:37, which turned the fragment from wrong into merely redundant — and then the cut consumed it. The objection was resolved twice over, by different means, neither of them this PR.Pull request closed