Releases as Code

A release needs to be reliable, which means it needs to be testable. A typical release selects a version, updates a changelog, builds an artifact, creates a commit and a tag, publishes the package, creates a GitHub Release, and often prepares the next development version. Projects add their own steps, such as updating version references in documentation, and these steps need to agree on what was released. If one breaks, the release fails halfway through, leaving a published package without a matching tag or a development version that wasn’t updated. You can’t always undo a published package and start over. Test your release code. Releases Are Software I’ve spent plenty of time maintaining release instructions, shell scripts, and GitHub Actions YAML. They automate the work, but the interesting logic tends to be spread across commands that are hard to exercise without actually making a release. I wanted to treat a release workflow like the rest of the project: write it in code,…

Commenting on Bubbles has been removed. Why? If you want to talk about this post, write to the author, use the comments on their blog if it has them, or reply with a "RE:" post on your own blog. Suggestions? feedback@bubbles.town