v1.44.0 ·
The release writes its own entry
Every release needed a person to pick the bump and hand-write a blog manifest entry. The v1.41.0 release failed once on exactly that. Two chore pull requests merged since the last tag were not declared in the entry.
The files an author wrote for a post carried the version number. That assumes the author knows the version while writing the deployment record. True for one person releasing by hand. False when two items build in parallel and release in whichever order CI finishes.
What changed
A new script looks at what merged since the last release. If any of it is a new feature, the release is a minor one. If it is only fixes and housekeeping, it is a patch. It then writes the release's blog entry.
When a piece of work has left the two small files that describe its post, the script checks that the post really builds before promising it. Otherwise the entry says there is no post, and quotes why. It also lists every merged branch that had no tracked piece of work behind it, which is the step v1.41.0 failed on earlier the same day.
The post files are now named after the piece of work, not the version, because when two pieces finish side by side nobody knows in advance which release will carry which.
Why this way
Re-implementing the blog generator's rules in a second place would have drifted from them. So the script drafts the entry, asks the generator itself to build the post in a scratch directory, and keeps the entry only if that works.
It never proposes a major release. A breaking change is a person's call. And it never runs the release. It writes the entry and says which bump, and the step that publishes stays separate. The aim was to take the person out of a step without taking out the check.