.github/workflows/tag-small-release.yml is empty. You’re drafting the check logic directly in this comment block before you write the actual workflow code, so you don’t miss any edge cases that tripped you up in past releases. Small releases make up 80% of the tags you push each quarter, so streamlining this process will save you hours of work over the course of a year, and cut down on the avoidable post-release issues that take time away from building new features. These three checks apply only to releases that include 5 or fewer commits, no breaking changes, and no major new feature launches that require full stakeholder signoff.
Validate no uncommitted hotfix overrides
Small releases often happen right after you’ve patched a critical bug for a single user, and it’s easy to leave a hardcoded override, temporary database connection string, or debug flag in your local codebase that doesn’t get committed to the main branch. If you tag a release from your local copy without checking, that override gets deployed to all users, leading to unexpected downtime or data leaks. Even if you think you stashed all your temporary work, it’s easy to forget a one-line change you made 2 days prior to test a user’s specific configuration, so running these four steps every single time eliminates that risk. The 2 minutes it takes to run these steps is a tiny investment compared to the hour or more it takes to roll back a bad release, answer support tickets from frustrated users, and fix the underlying issue after the fact.
To complete this check, follow these steps in order:
- Run `git status` to confirm no uncommitted changes exist in your working directory or staging area, stashing any in-progress work you don’t want included in the release.
- Search the entire codebase for comments marked `// HOTFIX-TEMP` or `# TEMP-OVERRIDE` to confirm no temporary code snippets are present in the main branch copy you’re tagging.
- Cross-reference the last 10 commit messages with the open issue tracker to confirm every commit included in the tag is tied to a resolved, tested issue.
- Run `git diff main origin/main` to confirm your local main branch is fully synced with the remote version, so you don’t tag a stale commit that’s missing critical merged fixes.
Illustrative example: Last month you tagged a v2.4.1 release without running this check, leaving a hardcoded rate limit override set to 10,000 requests per minute for a single enterprise user, which led to 1.2 million excess API requests in the first 2 hours after deployment, costing you $420 in overage fees before you caught the issue and rolled back.
Run the reduced smoke test suite
Full end-to-end test runs take 45 minutes to complete, which is overkill for small releases that only touch 1 or 2 isolated parts of the codebase. The reduced smoke test suite covers only the core functionality and the specific components modified in the release, taking less than 3 minutes to run from start to finish. It covers user authentication, core data entry flows, payment processing, and the specific feature or bug fix included in the current release. The reduced suite is configured to skip tests for legacy features that haven’t been modified in 6 months or more, and tests for admin-only tools that aren’t accessible to 99% of your user base. If the release you’re tagging only touches the password reset flow, for example, the smoke test will run the core authentication checks plus the full password reset flow, and skip all tests for the in-app messaging feature, payment processing, and file upload tool. That keeps the run time short without sacrificing coverage for the parts of the app that are actually changing. If any test fails, you don’t tag, you resolve the issue first, no exceptions. Even if the failed test seems unrelated, it’s better to delay the release by 10 minutes than deploy a broken build. Internal data shows that 70% of post-small-release bugs could have been caught by running this reduced test suite before tagging.
Confirm version bump alignment
Semantic versioning rules are easy to mix up when you’re rushing to push a small fix out before the end of the workday. A small release always gets a patch version bump (the third number in the MAJOR.MINOR.PATCH sequence) unless it includes a single, backward-compatible new feature, in which case it gets a minor version bump. You never bump the major version for a small release, no matter how big the bug fix feels. Last quarter, you accidentally bumped the minor version for a release that only included a single bug fix, leading to confusion for users who thought a new feature was being rolled out that wasn’t actually ready. That mistake led to 12 support tickets asking where the promised new feature was, taking 2 hours of your support team’s time to resolve. Running this check ensures that your version numbers always match the content of the release, so user expectations are aligned with what you’re actually shipping. To complete the check, first look at the current latest release tag on GitHub. Next, confirm the version number in your package.json, pyproject.toml, or other manifest file matches the version number you plan to use for the tag. Then, confirm the changelog has been updated with all the changes included in the release, dated for the current day, and linked to the relevant issue tickets. If you’re releasing a fix for a bug that was reported by multiple users, add a note in the changelog thanking the users who reported it, to build goodwill with your community. You also keep a public versioning guide linked in your changelog, so users can reference it if they ever have questions about what each part of the version number means.
Open this workflow file tomorrow to add pre-tag guardrails
Right now, all three checks are manual, which means there’s still a risk you’ll skip one when you’re stressed or in a hurry. When you open this file tomorrow, you’ll add automated steps that run all three checks automatically every time you attempt to push a new release tag to the remote repository, blocking the tag from being created if any check fails. You can reference the pre-built workflow snippets in the Build Next Stack documentation to cut down on the time you spend writing the workflow code, so you don’t have to build every step from scratch. You’ll start by adding the dependency validation step first, since that’s the check that caused the costly overage last month, then add the smoke test run, then add the version bump alignment check that scans the manifest file and changelog for consistency. You’ll also add a step that generates a draft release note automatically from the changelog entries, so you don’t have to copy and paste the changelog text into the GitHub release description manually. That step will also auto-tag any contributors who submitted pull requests included in the release, so they get notified that their work has been shipped, which encourages more community contributions over time. You don’t need to add any fancy custom logic to the workflow right away; even a basic version that runs the three checks and blocks bad tags will deliver most of the value, and you can iterate on it over time as you identify new edge cases to cover. Once the workflow is live, you’ll still run the checks manually for the first 5 releases to confirm the automation works as expected, before you rely on it fully. You’ll also include an optional step that sends a notification to your team’s Discord channel once a tag is successfully created, so everyone on the team knows a new release is rolling out, without you having to send a manual message every time.