Split them if you want different treatment for each, such as automerging patches and reviewing minors. Keep them together if you review everything by hand, because separate pull requests add noise. Some tools combine patch and minor into one pull request by default, so check what yours does before you decide.
What the defaults do
The documentation of one update bot says it groups patch and minor releases into a single pull request by default. Its example: you run version 1.0.0, and 1.0.1 and 1.1.0 both exist. You get one pull request, to 1.1.0. A setting turns that off and gives you separate branches for patch and minor. The documentation says separate updates are handy if you want to automerge patch updates but merge minor ones manually.
It has related settings too. By default, if several major versions exist, you get a pull request for the latest major only. A separate setting raises one pull request per major version, which suits teams that must step through versions in order.
Another major bot works differently. Its update types are first-class filters: you can allow, ignore or group by patch, minor or major, and a group can be limited to one or more of these levels.
Why the distinction matters
Semantic versioning says patch releases fix bugs without changing the interface, and minor releases add features compatibly. Many teams treat that as a risk scale. In practice it is a convention that maintainers follow with varying care, and the bot's own documentation warns that versions before 1.0.0 can make breaking changes at any time, and shows a rule to exclude them from automerge.
| Update level | Typical risk | Common policy |
|---|---|---|
| Patch | Lowest, often bug and security fixes | Automerge when tests pass |
| Minor | Low to medium, new features | Group, review the changelog |
| Major | Highest, may break | Separate pull request, approval first |
| Pre 1.0 | Unpredictable | Treat like major |
Decision steps
- Decide whether you will ever automerge. If not, splitting buys little.
- If yes, write the policy first: which levels, which dependency types, which tests must pass.
- Split patch from minor only for the dependency classes you plan to automerge. You do not need global separation.
- Keep security fixes outside this logic. A patch that fixes an advisory should not wait for a weekly group.
- Review the result after a month. Count how many separate patch pull requests merged untouched. If almost all did, your policy works. If you often fixed breakage, tighten it.
A middle path
Group all patch and minor updates for development dependencies into one pull request, automerge it when tests pass, and keep production dependencies individual until you trust your tests. This cuts the count sharply with little added risk. Our post on grouping updates without hiding risk shows what to keep out of any group.
Do not equate patch with safe
A patch to a package your code calls heavily can break you, and a minor release can contain a security fix you urgently need. Version level is a hint about risk, not a verdict. Pair it with tests and with knowledge of whether the package is reachable from your code.
Quick check
Does one pull request for patch and minor save time?
Usually, yes. Fewer pull requests mean fewer notifications and rebases, at the cost of a failure in one package blocking the rest.
Is a major update always a separate pull request?
In the documentation we read, major updates are separate by default for the first bot, and you can require approval before one is created.
Safeguard helps you rank updates by exposure. Reachability analysis shows which vulnerable dependencies your code actually calls, and policies and gates check pull requests before merge. It builds an SBOM from manifests and lockfiles. Fix pull requests are off by default, with every category on Manual. Run a free scan.
Sources
- Update bot documentation: configuration options, separate minor and patch
- Update bot documentation: automerge
- Code host documentation: update bot options reference, update types
Last reviewed: 19 October 2026.
