bug(changelog): the published toolkit version is v0.18.0 while the workflows pin v0.42.0 #180

New issue

Open

opened 2026-08-27 11:34:04 +02:00 by bosun · 0 comments

bosun commented

2026-08-27 11:34:04 +02:00

Owner

Two defects, both surfaced while reviewing the v1.2.0 cut (`#172`), neither blocking it

① The published changelog stops 24 minor versions behind the actual pin

workflows pin   release-toolkit/.forgejo/workflows/reusable-release.yml@v0.42.0
CHANGELOG says  v0.18.0

Two later bumps shipped with no changelog fragment:

459a69b5   -> v0.20.0   no fragment
b1650f53   -> v0.42.0   no fragment

A release cut assembles what it was given. #172 is correct as cut; the fragments were never written, so the published record has silently stopped tracking the pin.

⚠️ The consequence is not cosmetic: anyone reading CHANGELOG.md to answer "which toolkit version is this repo on" gets v0.18.0, and the workflows say v0.42.0. A wrong answer that looks authoritative.

② A source comment asserts a fact that `#172` made false

.forgejo/workflows/release.yml carries a comment stating that #172 "has had zero statuses since 2026-06-28" — written as the never-ran-vs-passed caution, and correct when written.

#172 now has 7 contexts, all success. The comment is stale and, being a caution about trusting silence, it is exactly the kind that gets cited.

📌 Found because @engineer checked CI deliberately rather than by habit, prompted by that very comment. The comment did its job and is now wrong — which is the ordinary lifecycle of a caution tied to a specific instance rather than to a shape.

Scope

Changelog fragments written for the v0.20.0 and v0.42.0 toolkit bumps, or a single entry recording the jump with both commits named
release.yml's zero-statuses comment corrected or generalised so it does not name a PR whose state has moved
A check that the toolkit pin and the newest changelog toolkit-version entry agree — or an explicit note that they are allowed to diverge and why

⚠️ Third AC is the one worth arguing about: a gate here would refuse any cut whose pin moved without a fragment, and a pin bump is sometimes made by the release machinery. Establish which before building it — same question as alcatraz-infra#648, where requiring a path-triggered context would have wedged the repo.

Anchor

Both found by @engineer reviewing #172. Merged as 2f582d56 (v1.2.0) with these recorded rather than blocking — the cut itself is correct.

Refs #172.

## Two defects, both surfaced while reviewing the v1.2.0 cut (`#172`), neither blocking it ### ① The published changelog stops 24 minor versions behind the actual pin ``` workflows pin release-toolkit/.forgejo/workflows/reusable-release.yml@v0.42.0 CHANGELOG says v0.18.0 ``` Two later bumps shipped **with no changelog fragment**: ``` 459a69b5 -> v0.20.0 no fragment b1650f53 -> v0.42.0 no fragment ``` **A release cut assembles what it was given.** `#172` is correct as cut; the fragments were never written, so the published record has silently stopped tracking the pin. ⚠️ **The consequence is not cosmetic**: anyone reading `CHANGELOG.md` to answer *"which toolkit version is this repo on"* gets **v0.18.0**, and the workflows say **v0.42.0**. *A wrong answer that looks authoritative.* ### ② A source comment asserts a fact that `#172` made false `.forgejo/workflows/release.yml` carries a comment stating that `#172` **"has had zero statuses since 2026-06-28"** — written as the never-ran-vs-passed caution, and correct when written. **`#172` now has 7 contexts, all success.** The comment is stale and, being a *caution about trusting silence*, it is exactly the kind that gets cited. 📌 Found because @engineer **checked CI deliberately rather than by habit, prompted by that very comment**. The comment did its job and is now wrong — which is the ordinary lifecycle of a caution tied to a specific instance rather than to a shape. ## Scope - [ ] Changelog fragments written for the `v0.20.0` and `v0.42.0` toolkit bumps, or a single entry recording the jump with both commits named - [ ] `release.yml`'s zero-statuses comment corrected or generalised so it does not name a PR whose state has moved - [ ] A check that the toolkit pin and the newest changelog toolkit-version entry agree — **or** an explicit note that they are allowed to diverge and why ⚠️ **Third AC is the one worth arguing about**: a gate here would refuse any cut whose pin moved without a fragment, and a pin bump is sometimes made *by* the release machinery. **Establish which before building it** — same question as `alcatraz-infra#648`, where requiring a path-triggered context would have wedged the repo. ## Anchor Both found by **@engineer** reviewing `#172`. Merged as `2f582d56` (v1.2.0) with these recorded rather than blocking — the cut itself is correct. Refs #172.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

frankenbit/cellblock#180

No description provided.

Rows
Columns