In vcpkg manifest mode, a builtin-baseline sets the default version for every dependency, while an override forces one exact version and ignores all other constraints. Use the baseline for steady, reproducible builds and an override when you must hold one library at a known version, for example while a fix is tested.
What each setting does
The Microsoft Learn reference for vcpkg versioning separates three ideas.
- Baseline. A global floor for the whole dependency graph. For the built-in registry it is the builtin-baseline field, a commit hash of the registry. It lets you keep every dependency current without writing a constraint for each one.
- version>=. A minimum for one dependency. vcpkg selects the lowest version that satisfies all constraints, so you rarely need an upper bound.
- overrides. Forces vcpkg to ignore all other version constraints and use the version you name. The docs describe it as useful for pinning exact versions and for resolving conflicts.
Versioning only works in manifest mode. If a manifest has no baseline and no registries configured, vcpkg falls back to classic mode and ignores versioning information. That fallback is easy to hit by accident.
A decision guide
| Situation | Use |
|---|---|
| Normal release build, want a stable known set | Baseline, committed in vcpkg.json |
| A library needs at least a fixed version | version>= on that library |
| A transitive dependency pulls an older release you cannot accept | Override |
| Need to freeze one library while the rest moves | Override, with a note and a review date |
Keep overrides short lived
An override is a promise that you will remember why you pinned. Add a comment in your change description, or a tracking issue, and review it when the baseline moves. An override that outlives the reason for it can quietly hold a vulnerable version in place long after a fix exists.
The same applies to the baseline. Bumping it is the moment your dependency set changes, so treat a baseline update as a reviewed pull request with a changed-versions summary, not a routine refresh.
Tie it to your SBOM
Whatever vcpkg resolves is what belongs in your bill of materials. Generate the list from the resolved graph, not from the constraints you wrote, because the two can differ.
Where Safeguard fits
If you want an inventory your reviewers can query, Safeguard offers SBOM and dependency scanning with policies and gates on pull requests. It works from the source and manifests it supports. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Open a component and check which exact version is recorded. That is the number your baseline or override should be producing.
Click through it at your own pace, or open it full screen.
Quick check
Does vcpkg compare version-string with version?
No. By design vcpkg does not compare versions that use different schemes, so a version-string of 7.1.3 cannot be ordered against a version of 7.1.4.
Can an override add a package that nothing depends on?
No. For an override to take effect the package must already be part of the dependency graph, either declared at the top level or pulled in by another dependency.
Sources
Last reviewed: 19 October 2026.
