You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CHANGELOG.md's Unreleased section advertises as unshipped a body of work that shipped a month
ago, and the record of that work exists nowhere else in the file.
Evidence
The Unreleased entries cite #37, #38, #40–#43, #45–#47 — Phase 5 CPU reranker, Phase
6a GDN CPU reference, Phase 6b TurboQuant, and the associated contracts and fixtures.
The released sections cover #78, #84, #85, #87, #100, #110, #111. No Unreleased
reference appears in any released section.
v1.0.0 (2026-07-29) is the oldest release in the repo:
The cause is structural, not an oversight. release-please generates changelog sections from
conventional commits going forward from the release it manages, so anything predating its first
cut never receives a version heading. That work did ship — inside v1.0.0 — but the changelog has no
heading saying so.
Two failure modes follow, and they pull in opposite directions:
Leaving it: the file claims real, shipped capability is still unreleased. Anyone reading it to
decide what a version contains is misled.
Move the Unreleased entries under the ## [1.0.0] heading where the work actually landed, and
leave Unreleased empty for release-please to own going forward.
Two things to settle while folding rather than carrying across verbatim:
gh pr view resolves none of #37–#47 in this repo. Those references may point at issues, or
at another repo entirely. Correct them during the fold.
Whether backfilling a v1.0.0 body is the right convention here at all is a judgement about this
repo's changelog, worth deciding explicitly rather than silently inside a cleanup.
Done when:Unreleased is empty, no shipped capability is described as unreleased, and every
entry currently in that block is still findable in the file under the version that shipped it.
Provenance
Split out of #134, which correctly identified the defect and proposed deletion. Closed in favour of
this.
Finding
CHANGELOG.md'sUnreleasedsection advertises as unshipped a body of work that shipped a monthago, and the record of that work exists nowhere else in the file.
Evidence
The
Unreleasedentries cite#37,#38,#40–#43,#45–#47— Phase 5 CPU reranker, Phase6a GDN CPU reference, Phase 6b TurboQuant, and the associated contracts and fixtures.
The released sections cover
#78,#84,#85,#87,#100,#110,#111. NoUnreleasedreference appears in any released section.
v1.0.0(2026-07-29) is the oldest release in the repo:Why this matters
The cause is structural, not an oversight. release-please generates changelog sections from
conventional commits going forward from the release it manages, so anything predating its first
cut never receives a version heading. That work did ship — inside v1.0.0 — but the changelog has no
heading saying so.
Two failure modes follow, and they pull in opposite directions:
decide what a version contains is misled.
contained. That trades a wrong statement for a missing one, and a missing record is harder to
notice later than a wrong one.
Desired correction
Move the
Unreleasedentries under the## [1.0.0]heading where the work actually landed, andleave
Unreleasedempty for release-please to own going forward.Two things to settle while folding rather than carrying across verbatim:
gh pr viewresolves none of#37–#47in this repo. Those references may point at issues, orat another repo entirely. Correct them during the fold.
v1.0.0body is the right convention here at all is a judgement about thisrepo's changelog, worth deciding explicitly rather than silently inside a cleanup.
Done when:
Unreleasedis empty, no shipped capability is described as unreleased, and everyentry currently in that block is still findable in the file under the version that shipped it.
Provenance
Split out of #134, which correctly identified the defect and proposed deletion. Closed in favour of
this.