Say what each release gives people, in one place

[marcosqlbi]

The GitHub release body for a stable version has been the single line SQLBI Whiteboard <version>., and the alternative the pipeline offered — addChangeLog — is a list of commit subjects. That is the too-short and the too-verbose you described, and neither answers the only question a reader has: is this upgrade worth having.

CHANGELOG.md is now the one place release notes are written, and scripts/release-notes.ps1 the only thing that reads it. One ## <version> - <date> section per released version, one ### heading per thing a person would notice.

Three readers, none of which the other two can serve:

• Release notes on every pull request fails when Directory.Build.props changes VersionPrefix and no section exists for the new version.
• Azure Pipelines writes that section into the GitHub release body, before the release is created — so an unwritten changelog stops the release instead of being noticed after it is public. Only the releaseNotes input of the stable release task changed; nothing in the signing path.
• Publish site renders every section into site/changelog.html and refuses to deploy a published release that has no section.

changelog.html becomes What's new: it no longer fetches releases from the GitHub API and renders their markdown in the browser, so the notes ship as HTML that reads without scripting and can be indexed. The footer link across the site is renamed to match. Entries go back to 1.0.0, written from the merge history; earlier versions stay on GitHub, where their notes already are.

Pre-release Dev builds are exempt everywhere — they come from every merge and would bury the releases people actually choose between.

The gate is on the version bump rather than only on the release, so the notes are written while the change is fresh, by the person who made it. The release is still checked, because a release need not have come from a bump.

Verified locally: all three script modes (Verify, Markdown, Html); the pull-request gate against a real bump (1.2.1 → 1.2.2, passes), a no-bump case (skips), and a bump to an unwritten 1.3.0 (exits 1); the rendered page served over HTTP and checked against the site's own stylesheet; and the Markdown output confirmed as UTF-8 with its arrows intact. An unstyled render caught 1.2.22 September 2026 — version and date collided when the only separator was a CSS gap — so the separator is now a character in the markup.

The generated region is not committed, the way the release manifests are not: site/changelog.html holds a placeholder between its markers and the deployment fills it, so the page cannot drift from the changelog.

🤖 Generated with Claude Code