[Unreleased] sits above [0.7.0] in CHANGELOG.md, so under Keep a Changelog its contents are newer than the release below them. Every PR correctly appends there, and nothing folds it forward — so the gap silently reopens after each merge.
It reopened twice on 2026-08-14 alone. The second time it stranded all seven security fixes from #366, the VOD editor and the EXPERIMENTAL convention from #365 — nine entries a tag would have omitted.
That is not cosmetic: GHSA-7jqx points at these release notes, and the fix for its worst defect (0.7.0's own seal-at-rest migration leaving plaintext keys in the WAL) was in the section a tag would have skipped. An operator following the advisory to the notes would not have found it.
Twice in one day is a process gap, not two mistakes. A check that fails a release build when [Unreleased] is non-empty would have caught both without anyone reading the file — and this repo would expect that guard to be demonstrably able to fail.
[Unreleased]sits above[0.7.0]in CHANGELOG.md, so under Keep a Changelog its contents are newer than the release below them. Every PR correctly appends there, and nothing folds it forward — so the gap silently reopens after each merge.It reopened twice on 2026-08-14 alone. The second time it stranded all seven security fixes from #366, the VOD editor and the EXPERIMENTAL convention from #365 — nine entries a tag would have omitted.
That is not cosmetic: GHSA-7jqx points at these release notes, and the fix for its worst defect (0.7.0's own seal-at-rest migration leaving plaintext keys in the WAL) was in the section a tag would have skipped. An operator following the advisory to the notes would not have found it.
Twice in one day is a process gap, not two mistakes. A check that fails a release build when
[Unreleased]is non-empty would have caught both without anyone reading the file — and this repo would expect that guard to be demonstrably able to fail.