Fix changelog

Grandiras commented

2026-08-18 10:28:15 +00:00

Owner

Prod is right now on version 2.3 and everything we do is unreleased and will therefore be 2.4. Please fix this. Also shorten the release notes. There's far too much information in there, unimportant to most non-technical people.

In general, everything we do goes into an "Unreleased" section. Only if I manually trigger the prod release process, then we'll accumulate everything into a version changelog and create a new empty section for the next development cycle.

Prod is right now on version 2.3 and everything we do is unreleased and will therefore be 2.4. Please fix this. Also shorten the release notes. There's far too much information in there, unimportant to most non-technical people. In general, everything we do goes into an "Unreleased" section. Only if I manually trigger the prod release process, then we'll accumulate everything into a version changelog and create a new empty section for the next development cycle.

claude-bot was assigned by Grandiras

2026-08-18 10:28:17 +00:00

claude-bot commented

2026-08-18 10:28:21 +00:00

Collaborator

🤖 On it — follow along in the action run; the reply will link the full session transcript.

📜 Live transcript — updating every ~5 minutes while the task runs.

🤖 On it — follow along in [the action run](https://git.grandiras.net/Grandiras/claude-bot/actions/runs/275); the reply will link the full session transcript.  📜 [Live transcript](https://git.grandiras.net/Grandiras/claude-bot/src/branch/claude-logs/transcripts/Grandiras/Ponente/issue-104/run-275.md) — updating every ~5 minutes while the task runs.

claude-bot referenced this issue from a pull request that will close it,

2026-08-18 10:44:32 +00:00

Claude: changes for issue #104 #105

claude-bot commented

2026-08-18 10:44:33 +00:00

Collaborator

Pushed to claude/issue-104.

What was wrong

The dialog listed 2.4.0, 2.4.1, 2.5.0, 2.6.0 and 2.7.0 while production sits on v2.3.0 — five versions that were never tagged and that nobody outside the repository had ever seen. That is what guessing a version number in the pull request that writes the entry produces. Twenty-one bullets across them, several about where a button moved to.

What it does now

Everything goes into Changelog.Unreleased, and nothing but a release ever names a version. The five phantom versions are folded back into that one block — which is what 2.4.0 will be when you cut it. Releases now starts at the 2.3.0 that actually shipped.

The release promotes it. .claude/skills/release/scripts/promote-changelog.py X.Y.Z moves the whole block into Releases, dates it the day it is tagged, and leaves an empty block behind for the next cycle. It has a --check mode, refuses an empty block (a deploy fix gets no entry — that is correct, not a hole to fill), and refuses a v prefix. It is wired into the release skill as its own step before the tag, landing as a small release/vX.Y.Z PR since main is protected — which also means the final notes are on dev a minute before the tag ships them.

The copy is much shorter, which was the other half of the ask: 21 bullets → 6 for everything unreleased, and every older release is now two lines. ChangelogTests caps an entry at seven bullets and a bullet at 260 characters, so it cannot grow back quietly.

Latest and the "you haven't read this" dot stay about the newest release. The unreleased block has no version for a browser to remember and moves several times a week on dev, so it is there to be read rather than to nudge — the badge marks the newest release below it. On production the block is empty and the dialog is exactly what it was.

Verified

dotnet build Ponente.sln — 0 errors, 0 warnings; dotnet test — 287 passed (7 new/changed changelog tests).
Ran the real app (installed the .NET 10 SDK and Postgres in this container, ASPNETCORE_ENVIRONMENT=Development) and ran changelog.spec.js and install.spec.js against it — passed; the screenshots above are that instance. i18n.spec.js passed except one test that pins a cookie to localhost:8090, which my 127.0.0.1:5000 base URL cannot satisfy — unrelated to this change.
Ran the promotion script end-to-end on a scratch copy (2.4.0): the promoted, empty-Unreleased shape also builds and passes all 287 tests, so the state production will be in is covered too.

One thing left for you: the first release cut after this merges is the one that turns the block into 2.4.0 — nothing in the repo will do it on its own.

⏱ 15m 55s · 75 turns · tokens: 171.6k in / 49.1k out (+10142.9k cache-read)
📜 Full session transcript
→ Opened PR: #105

Pushed to `claude/issue-104`. ## What was wrong The dialog listed **2.4.0, 2.4.1, 2.5.0, 2.6.0 and 2.7.0** while production sits on `v2.3.0` — five versions that were never tagged and that nobody outside the repository had ever seen. That is what guessing a version number in the pull request that writes the entry produces. Twenty-one bullets across them, several about where a button moved to. ## What it does now **Everything goes into `Changelog.Unreleased`, and nothing but a release ever names a version.** The five phantom versions are folded back into that one block — which is what 2.4.0 will be when you cut it. `Releases` now starts at the 2.3.0 that actually shipped. **The release promotes it.** `.claude/skills/release/scripts/promote-changelog.py X.Y.Z` moves the whole block into `Releases`, dates it the day it is tagged, and leaves an empty block behind for the next cycle. It has a `--check` mode, refuses an empty block (a deploy fix gets no entry — that is correct, not a hole to fill), and refuses a `v` prefix. It is wired into the release skill as its own step *before* the tag, landing as a small `release/vX.Y.Z` PR since `main` is protected — which also means the final notes are on dev a minute before the tag ships them. **The copy is much shorter**, which was the other half of the ask: 21 bullets → 6 for everything unreleased, and every older release is now two lines. `ChangelogTests` caps an entry at seven bullets and a bullet at 260 characters, so it cannot grow back quietly. **`Latest` and the "you haven't read this" dot stay about the newest *release*.** The unreleased block has no version for a browser to remember and moves several times a week on dev, so it is there to be read rather than to nudge — the badge marks the newest release below it. On production the block is empty and the dialog is exactly what it was. ![What's new before and after: five untagged versions replaced by one "On the way" block, with 2.3.0 still the newest release](https://git.grandiras.net/attachments/3cf976a6-edf8-4507-a4ab-88475bd19012) ## Verified - `dotnet build Ponente.sln` — 0 errors, 0 warnings; `dotnet test` — **287 passed** (7 new/changed changelog tests). - Ran the real app (installed the .NET 10 SDK and Postgres in this container, `ASPNETCORE_ENVIRONMENT=Development`) and ran `changelog.spec.js` and `install.spec.js` against it — **passed**; the screenshots above are that instance. `i18n.spec.js` passed except one test that pins a cookie to `localhost:8090`, which my `127.0.0.1:5000` base URL cannot satisfy — unrelated to this change. - Ran the promotion script end-to-end on a scratch copy (`2.4.0`): the promoted, empty-`Unreleased` shape also builds and passes all 287 tests, so the state production will be in is covered too. One thing left for you: the first release cut after this merges is the one that turns the block into `2.4.0` — nothing in the repo will do it on its own. --- ⏱ 15m 55s · 75 turns · tokens: 171.6k in / 49.1k out (+10142.9k cache-read) 📜 [Full session transcript](https://git.grandiras.net/Grandiras/claude-bot/src/branch/claude-logs/transcripts/Grandiras/Ponente/issue-104/run-275.md) → Opened PR: https://git.grandiras.net/Grandiras/Ponente/pulls/105

changelog-before-after.png

1.6 MiB

Grandiras closed this issue

2026-08-18 10:56:28 +00:00

Grandiras referenced this issue from a commit

2026-08-18 10:56:30 +00:00

Claude: changes for issue #104 (#105)

claude-bot referenced this issue

2026-08-18 13:53:32 +00:00

Let's push out a new release to prod #106