Run the full suite by default, because CI minutes are cheaper than a bad release. Use a faster subset for a patch bump just when the package is low risk, the diff is small, tests are reliable, and a staged rollout will catch what slips through. Never skip tests because of the version number alone.
What a patch version promises
Semantic Versioning says a patch version increments when you make backward compatible bug fixes, and that a bug fix is an internal change that fixes incorrect behavior. A patch should not change your public contract. In practice the promise holds most of the time, which is why teams are tempted to merge patch bumps untested.
The weak points are real. Fixing a bug changes behavior, and someone may depend on the buggy behavior. Maintainers can mislabel a release. And the version rule says nothing about packages in major version zero, where anything may change at any time.
A rule for choosing the test depth
Score the bump on four questions. Each yes pushes you toward the full suite.
- Does the package sit on a trust boundary, such as authentication, cryptography, serialization, a database driver or an HTTP client?
- Is the diff large for a patch, or does the changelog mention behavior changes?
- Is the package pre 1.0?
- Is your test suite flaky or thin around the code that uses this package?
| Answers | Test depth |
|---|---|
| All no | Unit tests for callers plus a smoke test |
| One yes | Full unit and component suite plus smoke test |
| Two or more yes | Full suite, integration tests and a canary rollout |
If the bump fixes a vulnerability you are exposed to, the stakes shift. Delay costs risk, so make the full suite fast enough to run immediately rather than deciding to skip it. See emergency patch versus routine patch criteria for how to decide urgency.
Make the full suite cheap enough to always run
The usual reason teams skip tests is time. Fix the time, not the discipline.
- Split the suite so unit tests return in minutes, with slower integration tests in parallel jobs.
- Cache dependencies and build layers keyed by lockfile hash.
- Quarantine flaky tests with an owner and a deadline, so a red build means something.
- Group related low risk bumps into one pull request so you run the suite once.
If you use a bot to open update pull requests, consider grouping settings. GitHub documents a groups option in the Dependabot configuration that lets you bundle updates into a single pull request.
What to do after merge
A passing suite is not the end. Deploy through a staged rollout and watch error rate and latency on the new version compared with the old. Google's SRE guidance describes canarying as comparing a small subset of production against a control portion, which is how you catch what tests cannot. Our post on canary release metrics lists what to compare.
Safeguard can open fix pull requests for vulnerable dependencies, off by default with every category on Manual, and run your policy gates on them, so the suite and rollout rules apply to automated changes the same way as human ones.
Quick check
Is it ever fine to auto-merge patch bumps?
Sometimes, for low risk packages with strong tests and a staged rollout behind them. Keep trust boundary packages and anything pre 1.0 on manual review.
What if the full suite takes an hour?
Treat that as the bug. Parallelize, cache and quarantine flaky tests until the suite fits your urgent patch window.
Sources
- Semantic Versioning 2.0.0
- Dependabot configuration options, GitHub Docs
- Canarying Releases, Google SRE Workbook
Last reviewed: 19 October 2026.
