Each version additionally has a "port-version" which is a nonnegative integer. When rendered as text, the
port version (if nonzero) is added as a suffix to the primary version text separated by a hash (#).
Port-versions are sorted lexographically after the primary version text, for example:
1.0.0 <1.0.0#1<1.0.1<1.0.1#5<2.0.0
## Constraints
Manifests can place three kinds of constraints upon the versions used:
### builtin-baseline
The baseline references a commit within the vcpkg repository that
establishes a minimum version on every dependency in the graph. If
no other constraints are specified (directly or transitively),
then the version from the baseline of the top level manifest will
be used.
You can get the current commit of your vcpkg instance either by adding an empty `"builtin-baseline"` field, installing, and examining the error message or by running `git rev-parse HEAD` in the root of the vcpkg instance.
Baselines provide stability and ease of development for top-level manifest files. They are not considered from ports consumed as a dependency. If a minimum version constraint is required during transitive version resolution, the port should use `version>=`.
### version>=
Within the "dependencies" field, each dependency can have a
minimum constraint listed. These minimum constraints will be used
when transitively depending upon this library. A minimum
port-version can additionally be specified with a '#' suffix.
This constraint must refer to an existing, valid version (including port-version).
### overrides
When used as the top-level manifest (such as when running `vcpkg
install` in the directory), overrides allow a manifest to
short-circuit dependency resolution and specify exactly the
version to use. These can be used to handle version conflicts,
such as with `version-string` dependencies.
Overrides are not considered from ports consumed as a dependency.
