chore(release): v0.60.0 #1230
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
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
frankenbit/release-toolkit!1230
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "release-prep/rolling"
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?
Changelog density — clean
28w: **workflow ref resolution**: the caller fallback now accepts absolute ...Advisory mirror of the cut-time gate, computed when this description was written. It carries no authority: the cut re-runs these checks against the section as it stands then, and this branch is recreated from
mainon every compose.Added
rt prep-order-checkrefuses a PR that stacks a release-relevant commit above its prepare commit (#1170).rt build-ref-checkrefuses a tagged tree that does not carry its own tag (#1214).secrets: inheritis now reported, not silent (#1258)Changed
.giteatwin is generated alongside the Forgejo source (#1200).Fixed
.giteatwins alongside the sources it bakes (#1180).frankenbit/release-toolkitwrapper paths when a reusable's baked marker is absent or still the placeholder (#1222).PRCommitSHAsandPRCommitMessagesnow paginate, and refuse a malformed page (#1223).#1232).#1233).REQUEST_CHANGES(#1235).REQUEST_CHANGES(#1246).internal/bakecompiles again after two PRs exported the same accessor (#1270).Removed
None.
Deprecated
None.
Upgrade
None.
Internal
assets-presentjob's release-keyed decision and its could-not-grade refusal now have behavioural arms (#1257).NeedsSecretsis now derived-and-asserted, not just hand-maintained (#1269)chore(release): v0.59.1to chore(release): v0.60.06be6f080c6ba90876c1bba90876c1bb17a1bdf8fb17a1bdf8f982b1927cf982b1927cfcdd5e7a144cdd5e7a144351abcb567351abcb5673005ccf8fa3005ccf8faa0d8884ee3a0d8884ee3b151e9ad4ab151e9ad4a95c9305b4895c9305b48a99a1822c6a99a1822c6ad4b509947ad4b5099475112dada085112dada084139053b3c4139053b3cc757bc0565APPROVED at
c757bc05. Twenty-five fragments, every one accounted for, and the bake is complete — checked by PARSING rather than grepping, because grepping gave me a false finding first.The bake
⚠️ A
grepfor the marker reports ONE file still holding'main'—.forgejo/workflows/build-ref-check.yml. That is comment text, quotingv1.0.0-alpha.0's shipped value inside the positive-control documentation. Parsingjobs[].steps[].envfinds 18 real markers and no unbaked one. Recording it because the next person to verify a cut will reach for the same grep and get the same false hit — and on a release cut, "one file still says main" is the finding you least want to be wrong about in either direction.✅ And the live verb agrees, both directions:
📌 Note what it does NOT cover, which it says itself: the
.giteatwins. It grades 8 marker-carrying canonical.forgejofiles; my parse covers all 18 including the twins, and they are baked too. The two together are stronger than either.Fragments — twenty-five, reconciled both directions
Counted, not read. A fragment lost between the directory and the section is invisible in a rendered view: the section still looks complete, and the only evidence is a file that vanished without a bullet.
Scope
Not graded: the content of the twenty-five changes, each reviewed on its own PR — eight of them by me this cycle. Not re-derived: the bump itself;
rt prepcomputes it and I confirmed only that anaddedfragment exists and that minor follows.⚠️ This stamp expires the moment anything else merges. Three of my stamps on the previous cut were spent that way, and the rule that avoids it is @bosun's: review the cut LAST. Main is quiet as I write this and
base.sha == merge_base; if that changes before the merge, this needs re-reading rather than trusting.📌 One thing worth having on the record for the release notes:
#1214is in this cut — the tracker forv1.0.0-alpha.0shipping an unbaked marker. So v0.60.0 both fixes that class and is itself verified clean of it, by the verb the fix added.c757bc0565949d1b0860New commits pushed, approval review dismissed automatically according to repository settings
949d1b0860bd4969c959APPROVED at
bd4969c9— third re-stamp. The CONTENT is right; merge when the gate goes green.✅ The re-roll FIXED the one thing I was going to disclose. At
949d1b08,changelog.d/1269.internal.mdwas onmainand absent from the section — this head carries it. Every fragment on main now appears in the v0.60.0 notes. Nothing deferred, nothing lost.🔑 Why I am stamping with CI still running, deliberately
Two of my stamps have died to this branch and three to the previous cut. Waiting for 28 contexts to settle is another five-minute window in which the bot re-rolls and this stamp dies too — and the wait buys nothing, because a review row is not what enforces CI.
Those are different claims and only one of them is mine.
enable_status_check=truewith 27 required contexts means @bosun cannot merge a red tree whatever I say — so gating my stamp on CI adds no protection and costs the stamp.⚠️ What this stamp does NOT assert: that CI passed. It was 28-pending when I filed. Read the required set at merge time; that is the check that matters and it is not this one.
Everything re-derived at this head
Bake parsed from
jobs[].steps[].env, not grepped. ⚠️ A grep still reports one file holding'main'— comment text inbuild-ref-check.ymlquotingv1.0.0-alpha.0's shipped value. Positive control: the same parser onorigin/mainreports'main' x18, so the zero is a measurement rather than a blind spot.📌 @bosun — your freeze is the right instrument and this branch is why: every merge that makes the cut more current also dismisses the stamp saying it is. This is the third head I have graded in twenty minutes and the first where nothing is outstanding. Merge it.