For an application, let the bot raise the minimum version to the one it updated to. For a library, widen the allowed range so it includes both old and new versions, so your consumers are not forced to upgrade. The bot's default tries to tell the two apart, so confirm it guessed right.
Two kinds of project, two needs
An application is deployed. You control its lockfile and the exact versions it runs. Raising a minimum to match the new version is safe and keeps the manifest honest about what you tested.
A library is consumed by others. If it raises its minimum, every consumer that also uses the dependency may be forced to upgrade, and conflicts can appear in trees you do not control. A library should allow a wide span of versions so the consumer's own choice wins.
What the documentation describes
The options reference of one major bot has a versioning strategy setting for several ecosystems: bundler, cargo, composer, helm, mix, npm, pip, pub and uv. Its default tries to tell apps from libraries. For apps, it always increases the minimum version requirement to match the new version, called the increase strategy. For libraries, it widens the allowed requirements to include both old and new versions when possible, called the widen strategy. If you set a strategy yourself, the tool uses it everywhere in that entry. A further value, auto, restores the default, and another, increase if necessary, edits the range only when the new version falls outside it.
The second bot documents a related default for vulnerability fixes. Its vulnerability configuration uses a range strategy that updates the lockfile and a fix strategy that chooses the lowest version that resolves the issue. That fits the same instinct: when fixing a library or a shared tree, move as little as you can.
A decision table
| Project type | Suggested range edit | Reason |
|---|---|---|
| Deployed application | Increase minimum | Manifest matches what you test |
| Published library | Widen range | Consumers keep their freedom |
| Internal shared package | Widen, with a tested floor | Many apps consume it |
| Security fix in a library | Raise the floor to the fixed version, then widen above it | Excludes the vulnerable release |
Security trap in widening
Widening a range to include a new version can leave the old, vulnerable version still allowed. A consumer's resolver may pick it. For a security fix in a library, raise the floor to the first fixed release so the vulnerable ones are excluded. Pure widening protects compatibility, not safety.
Steps to check your setup
- Decide whether each repository is an application or a library, and write it down.
- Read what strategy the bot is using. Check a recent pull request: did it change the manifest line, and how?
- Where the guess is wrong, set the strategy explicitly for that entry.
- For a library, test against the lowest and highest versions in your range in CI.
- For security fixes, make sure the floor excludes affected releases.
Our post on committing lockfiles for apps and libraries covers the lockfile side of the same split.
Quick check
Why did the bot change my manifest line and not only the lockfile?
Because its strategy edits the declared range. For an application, the default raises the minimum to the new version.
Can widening cause a vulnerable version to be installed?
Yes, if the old version stays in range. Raise the floor to the first fixed release for security fixes.
Safeguard builds an SBOM from manifests and lockfiles and flags dependencies with known advisories, and policies and gates check pull requests before merge. Reachability analysis shows which flagged packages your code calls. Fix pull requests are off by default, with every category on Manual. A free scan is available.
Sources
- Code host documentation: update bot options reference, versioning strategy
- Update bot documentation: configuration options, vulnerability alerts
Last reviewed: 19 October 2026.
