v1.44.0 ·
The release writes its own entry
The problem
Every release needs a person to pick the bump and hand-write a blog manifest entry. Today's
v1.41.0 release failed once on exactly that: two chore PRs merged since the last tag were not
declared in the entry. Version-named overrides (overrides/v1.41.0-options.md) assume 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.
How it could be solved
Three decisions, each about taking the person out of a step without taking out the check.
The first was who decides whether a release gets a post. Re-implementing the blog generator's rules in a second place would have drifted from them. So the tool drafts the post entry, then asks the generator itself to build the post in a scratch directory, and keeps the entry only if that works. When it does not, the entry says there is no post and quotes why.
The second was what to name the files an author writes for a post. They used to carry the version number, which a person releasing by hand knows in advance. When two pieces of work build side by side and release in whichever order they finish, nobody knows the number while writing. So the files are now named after the piece of work instead.
The third was what the tool may never decide. It picks between a minor and a patch release from the kind of branches merged, but it never proposes a major one: a breaking change is a person's call. And it never runs the release itself; it writes the entry and says which bump, and the step that publishes stays separate.
How AIDLC solves it
A release no longer needs someone to decide its version or write its blog entry by hand. A new script looks at what was 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, a patch. It never proposes a major release, because a breaking change is a person's call. 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 why. It also lists every merged branch that had no tracked piece of work behind it, which is the step a release failed on earlier the same day.
The post files are now named after the piece of work rather than the version, because when two pieces of work finish side by side nobody knows in advance which release will carry which.