yuzu/vcpkg
1
0
Fork 0
mirror of https://github.com/microsoft/vcpkg synced 2024-11-21 16:09:03 -07:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

[docs] Consolidate versioning documentation (#17580)

Browse source 
Co-authored-by: Robert Schumacher <ras0219@outlook.com>
This commit is contained in:
Robert Schumacher 2021-05-03 09:43:34 -07:00 committed by GitHub
parent 4b6289b936
commit 2924119c1e
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
6 changed files with 268 additions and 339 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

23
docs/examples/versioning.getting-started.md
View file

@ -176,27 +176,19 @@ If you want to upgrade your dependencies, you can bump the minimum version const
#### **`builtin-baseline`**
```
"builtin-baseline": "b60f003ccf5fe8613d029f49f835c8929a66eb61"
```json
{ "builtin-baseline": "b60f003ccf5fe8613d029f49f835c8929a66eb61" }
```
This field declares the versioning baseline for all ports. Setting a baseline is required to enable versioning, otherwise you will get the current versions on the ports directory. You can run 'git rev-parse HEAD' to get the current commit of vcpkg and set it as the builtin-baseline. But what is a baseline? What does it do? Why is the value a SHA?
From the [versioning documentation](../users/versioning.md):
> 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.
This field declares the versioning baseline for all ports. Setting a baseline is required to enable versioning, otherwise you will get the current versions on the ports directory. You can run 'git rev-parse HEAD' to get the current commit of vcpkg and set it as the builtin-baseline. See the [`builtin-baseline` documentation](../users/versioning.md#builtin-baseline) for more information.
In our example, you can notice that we do not declare a version constraint for `zlib`; instead, the version is taken from the baseline. Internally, vcpkg will look in commit `b60f003ccf5fe8613d029f49f835c8929a66eb61` to find out what version of `zlib` was the latest at that point in time (in our case it was `1.2.11#9`).
During version resolution, baseline versions are treated as minimum version constraints. If you declare an explicit constraint that is lower than a baseline version, the explicit constraint will be upgraded to the baseline version.
For example, if we modified our dependencies like this:
```
"dependencies": [
```json
{ "dependencies": [
{
"name": "fmt",
"version>=": "7.1.3"
@ -205,7 +197,7 @@ For example, if we modified our dependencies like this:
"name": "zlib",
"version>=": "1.2.11#7"
}
]
] }
```
_NOTE: The value `1.2.11#7` represents version `1.2.11`, port version `7`._
@ -224,7 +216,7 @@ The mechanism vcpkg provides for that scenario is `overrides`. When an override
Let's modify our example once more, this time to force vcpkg to use version `6.0.0` of `fmt`.
```
```json
{
"name": "versions-test",
"version": "1.0.0",
@ -289,5 +281,4 @@ See also:
* [Versioning docs](../users/versioning.md)
* [Original specification](../specifications/versioning.md)
* [Versioning reference](../users/versioning.reference.md)
* [Versioning implementation details](../users/versioning.implementation-details.md)

2
docs/maintainers/maintainer-guide.md
View file

@ -241,7 +241,7 @@ To update the files for all modified ports at once.
_NOTE: These commands require you to have committed your changes to the ports before running them. The reason is that the Git SHA of the port directory is required in these version files. But don't worry, the `x-add-version` command will warn you if you have local changes that haven't been committed._
See our [versioning specification](https://github.com/vicroms/vcpkg/blob/versioning-spec/docs/specifications/versioning.md) and [registries specification](https://github.com/strega-nil/vcpkg/blob/git-registries/docs/specifications/registries-2.md) to learn how vcpkg interacts with these files.
See our [versioning specification](../specifications/versioning.md) and [registries specification](../specifications/registries-2.md) to learn how vcpkg interacts with these files.
## Patching

3
docs/users/config-environment.md
View file

@ -16,8 +16,9 @@ subject to change without notice and should be considered highly unstable.
Non-exhaustive list of off-by-default features:
- `binarycaching`
- `manifest`
- `versions`
- `registries`
#### EDITOR

4
docs/users/manifests.md
View file

@ -88,7 +88,7 @@ You shouldn't need to worry about this at all.
**Experimental behind the `versions` feature flag**
See [versioning.md](versioning.md#version%20schemes) for additional version types.
See [versioning](versioning.md#version-schemes) for additional version types.
### `"description"`
@ -189,7 +189,7 @@ A minimum version constraint on the dependency.
This field specifies the minimum version of the dependency using a '#' suffix to denote port-version if non-zero.
See also [versioning](versioning.md#constraints) for more semantic details.
See also [versioning](versioning.md#version-1) for more semantic details.
### `"overrides"`

345
docs/users/versioning.md
View file

@ -1,89 +1,256 @@
# Versioning
**The latest version of this documentation is available on [GitHub](https://github.com/Microsoft/vcpkg/tree/master/docs/users/versioning.md).**
**This feature is experimental and requires `--feature-flags=versions`**
Versioning allows you to deterministically control the precise revisions of dependencies used by
your project from within your manifest file.
See our guide to [getting started with versioning](../examples/versioning.getting-started.md).
## Version schemes
### Schemes
Versions in vcpkg come in four primary flavors:
#### version
A dot-separated sequence of numbers (1.2.3.4)
#### version-date
A date (2021-01-01.5)
#### version-semver
A Semantic Version 2.0 (2.1.0-rc2)
See https://semver.org/ for a full specification.
#### version-string
An exact, incomparable version (Vista)
### Port Versions
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.
## Example top-level manifest:
```json
{
"name": "example",
"version": "1.0",
"builtin-baseline": "a14a6bcb27287e3ec138dba1b948a0cdbc337a3a",
"dependencies": [
{ "name": "zlib", "version>=": "1.2.11#8" },
"rapidjson"
],
"overrides": [
{ "name": "rapidjson", "version": "2020-09-14" }
]
}
```
See also the [manifest documentation](manifests.md) for more syntax information.
## Original Specification
See also the [original specification](https://github.com/microsoft/vcpkg/blob/master/docs/specifications/versioning.md)
# Versioning
**The latest version of this documentation is available on [GitHub](https://github.com/Microsoft/vcpkg/tree/master/docs/users/versioning.md).**
Versioning allows you to deterministically control the precise revisions of dependencies used by
your project from within your manifest file.
See our guide to [getting started with versioning](../examples/versioning.getting-started.md).
## Contents
* [Version schemes](#version-schemes)
* [`version`](#version)
* [`version-semver`](#version-semver)
* [`version-date`](#version-date)
* [`version-string`](#version-string)
* [Version constraints](#version-constraints)
* [Version files](#version-files)
## Version schemes
Ports in vcpkg should attempt to follow the versioning conventions used by the package's authors. For that reason, when declaring a package's version the appropriate scheme should be used.
Each versioning scheme defines its own rules on what is a valid version string and more importantly the rules for how to sort versions using the same scheme.
The versioning schemes understood by vcpkg are:
Manifest property | Versioning scheme
------------------|------------------------------------
`version` | For dot-separated numeric versions
`version-semver` | For SemVer compliant versions
`version-date` | For dates in the format YYYY-MM-DD
`version-string` | For arbitrary strings
A manifest must contain only one version declaration.
#### `version`
Accepts version strings that follow a relaxed, dot-separated-, semver-like scheme.
The version is logically composed of dot-separated (`.`) numeric sections. Each section must contain an integer positive number with no leading zeroes.
The regex pattern for this versioning scheme is: `(0|[1-9]\d*)(\.(0|[1-9]\d*))*`
_Sorting behavior_: When comparing two versions, each section is compared from left to right by their numeric value, until the first difference is found. A version with the smallest set of sections takes precedence over another with a larger set of sections, given that all their preceding sections compare equally.
Example:
`0` < `0.1` < `0.1.0` < `1` < `1.0.0` < `1.0.1` < `1.1`< `2.0.0`
#### `version-semver`
Accepts version strings that follow semantic versioning conventions as described in the [semantic versioning specification](https://semver.org/#semantic-versioning-specification-semver).
_Sorting behavior_: Strings are sorted following the rules described in the semantic versioning specification.
Example:
`1.0.0-1` < `1.0.0-alpha` < `1.0.0-beta` < `1.0.0` < `1.0.1` < `1.1.0`
#### `version-date`
Accepts version strings that can be parsed to a date following the ISO-8601 format `YYYY-MM-DD`. Disambiguation identifiers are allowed in the form of dot-separated-, positive-, integer-numbers with no leading zeroes.
This is the recommended versioning scheme for "Live at HEAD" libraries that don't have established release versions.
The regex pattern for this versioning scheme is: `\d{4}-\d{2}-\d{2}(\.(0|[1-9]\d*))*`
_Sorting behavior_: Strings are sorted first by their date part, then by numeric comparison of their disambiguation identifiers. Disambiguation identifiers follow the rules of the relaxed (`version`) scheme.
Examples:
`2021-01-01` < `2021-01-01.1` < `2021-02-01.1.2` < `2021-02-01.1.3` < `2021-02-01`
#### `version-string`
For packages using version strings that do not fit any of the other schemes, it accepts most arbitrary strings. The `#` which is used to denote port versions is disallowed.
_Sorting behavior_: No sorting is attempted on the version string itself. However, if the strings match exactly, their port versions can be compared and sorted.
Examples:
* `apple` <> `orange` <> `orange.2` <> `orange2`
* `watermelon#0`< `watermelon#1`
#### `port-version`
A positive integer value that increases each time a vcpkg-specific change is made to the port.
The rules for port versions are:
* Start at 0 for the original version of the port,
* increase by 1 each time a vcpkg-specific change is made to the port that does not increase the version of the package,
* and reset to 0 each time the version of the package is updated.
_NOTE: Whenever vcpkg output a version it follows the format `<version>#<port version>`. For example `1.2.0#2` means version `1.2.0` port version `2`. When the port version is `0` the `#0` suffix is omitted (`1.2.0` implies version `1.2.0` port version `0`)._
_Sorting behavior_: If two versions compare equally, their port versions are compared by their numeric value, lower port versions take precedence.
Examples:
* `1.2.0` < `1.2.0#1` < `1.2.0#2` < `1.2.0#10`
* `2021-01-01#20` < `2021-01-01.1`
* `windows#7` < `windows#8`
## Version constraints
### `builtin-baseline`
Accepts a Git commit ID. Vcpkg will try to find a baseline file in the given commit ID and use that to set the baseline versions (lower bounds) of all dependencies.
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>=`.
Example:
```json
{
"name": "project",
"version": "1.0.0",
"dependencies": ["zlib", "fmt"],
"builtin-baseline":"9fd3bd594f41afb8747e20f6ac9619f26f333cbe"
}
```
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.
When resolving version constraints for a package, vcpkg will look for a baseline version:
* First by looking at the baseline file in the given commit ID.
* If the given commit ID does not contain a baseline file, vcpkg will fallback to use the local baseline file instead.
* If there's no local baseline file, vcpkg will use the version currently available in the ports directory.
_NOTE: If a baseline file is found, but it does not contain an entry for the package, the vcpkg invocation will fail._
### `version>=`
Expresses a minimum version requirement, `version>=` declarations put a lower boundary on the versions that can be used to satisfy a dependency.
**Note: Vcpkg selects the lowest version that matches all constraints, so a less-than constraint is not required.**
Example:
```json
{
"name": "project",
"version-semver": "1.0.0",
"dependencies": [
{ "name": "zlib", "version>=": "1.2.11#9" },
{ "name": "fmt", "version>=": "7.1.3" }
],
"builtin-baseline":"9fd3bd594f41afb8747e20f6ac9619f26f333cbe"
}
```
As part of a version constraint declaration, a port version can be specified by adding the suffix `#<port-version>`, in the previous example `1.2.11#9` refers to version `1.2.11` port version `9`.
### `overrides`
Declaring an override forces vcpkg to ignore all other version constraints and use the version specified in the override. This is useful for pinning exact versions and for resolving version conflicts.
Overrides are declared as an array of package version declarations.
For an override to take effect, the overridden package must form part of the dependency graph. That means that a dependency must be declared either by the top-level manifest or be part of a transitive dependency.
```json
{
"name": "project",
"version-semver": "1.0.0",
"dependencies": [
{ "name": "zlib", "version>=": "1.2.11#9" },
"fmt"
],
"builtin-baseline":"9fd3bd594f41afb8747e20f6ac9619f26f333cbe",
"overrides": [
{ "name": "fmt", "version": "6.0.0" }
]
}
```
## Version files
Vcpkg uses a set of metadata files to power its versioning feature.
These files are located in the following locations:
* `${VCPKG_ROOT}/versions/baseline.json`, (this file is common to all ports) and
* `${VCPKG_ROOT}/versions/${first-letter-of-portname}-/${portname}.json` (one per port).
For example, for `zlib` the relevant files are:
* `${VCPKG_ROOT}/versions/baseline.json`
* `${VCPKG_ROOT}/versions/z-/zlib.json`
The vcpkg public CI checks validate that each time a port is added or updated its respective version files are also updated.
### Baseline file
The baseline file located in `${VCPKG_ROOT}/versions/baseline.json` is used to declared the current baseline versions of all packages.
For example:
```json
{
"default": {
"3fd": { "baseline": "2.6.3", "port-version": 0 },
"7zip": { "baseline": "19.00", "port-version": 2 },
"abseil": { "baseline": "2020-09-23", "port-version": 1 }
}
}
```
Provided that there are no local modifications to the ports, the versions of all packages in the baseline file should map to the version of their corresponding portfiles in the `ports/` directory.
### Versions file
Each port in vcpkg has a corresponding versions file, the location of a port's versions file follows the pattern:
```sh
${VCPKG_ROOT}/versions/${first-letter-of-portname}-/${portname}.json
```
For example, for `zlib` the corresponding versions file is:
```sh
${VCPKG_ROOT}/versions/z-/zlib.json
```
These files contain an array of all the versions available for a given port.
For example, the contents of `versions/z-/zlib.json` declare the following versions:
```json
{
"versions": [
{
"git-tree": "827111046e37c98153d9d82bb6fa4183b6d728e4",
"version-string": "1.2.11",
"port-version": 9
},
{
"git-tree": "068430e3e24fa228c302c808ba99f8a48d126557",
"version-string": "1.2.11",
"port-version": 8
},
...
]
}
```
Each version declared in this file uses the same syntax used in manifest files, but adds an extra `git-tree` property. The value of `git-tree` is the SHA hash, as calculated by Git, of the directory containing the portfiles for the declared version. You can ask Git for the object SHA via the syntax:
```
git rev-parse <commit>:<path>
```
For example,
```
git rev-parse HEAD:ports/zlib
```
### Updating the version files
The recommended method to update these files is to run the `x-add-version` command.
For example, if you have made changes to `zlib`:
```
vcpkg x-add-version zlib
```
If you're updating multiple ports at the same time, instead you can run:
```
vcpkg x-add-version --all
```
To update the files for all modified ports at once.
_NOTE: These commands require you to have committed your changes to the ports before running them. The reason is that the Git SHA of the port directory is required in these version files. But don't worry, the `x-add-version` command will warn you if you have local changes that haven't been committed._
## See Also
* The [implementation details](versioning.implementation-details.md)
* The [original specification](../specifications/versioning.md)

230
docs/users/versioning.reference.md
View file

@ -1,230 +0,0 @@
# Versioning reference
**The latest version of this documentation is available on [GitHub](https://github.com/Microsoft/vcpkg/tree/master/docs/users/versioning.reference.md).**
## Contents
* [Version schemes](#version-schemes)
* [Version files](#version-files)
* [Version constraints](#version-constraints)
## Version schemes
Ports in vcpkg should attempt to follow the versioning conventions used by the package's authors. For that reason, when declaring a package's version the appropriate scheme should be used.
Each versioning scheme defines its own rules on what is a valid version string and more importantly the rules for how to sort versions using the same scheme.
The versioning schemes understood by vcpkg are:
Manifest property | Versioning scheme
------------------|------------------------------------
`version` | For dot-separated numeric versions
`version-semver` | For SemVer compliant versions
`version-date` | For dates in the format YYYY-MM-DD
`version-string` | For arbitrary strings
A manifest must contain only one version declaration.
#### `version`
Accepts version strings that follow a relaxed, dot-separated-, semver-like scheme.
The version is logically composed of dot-separated (`.`) numeric sections. Each section must contain an integer positive number with no leading zeroes.
The regex pattern for this versioning scheme is: `(0|[1-9]\d*)(\.(0|[1-9]\d*))*`
_Sorting behavior_: When comparing two versions, each section is compared from left to right by their numeric value, until the first difference is found. A version with the smallest set of sections takes precedence over another with a larger set of sections, given that all their preceding sections compare equally.
Example:
`0` < `0.1` < `0.1.0` < `1` < `1.0.0` < `1.0.1` < `1.1`< `2.0.0`
#### `version-semver`
Accepts version strings that follow semantic versioning conventions as described in the [semantic versioning specification](https://semver.org/#semantic-versioning-specification-semver).
_Sorting behavior_: Strings are sorted following the rules described in the semantic versioning specification.
Example:
`1.0.0-1` < `1.0.0-alpha` < `1.0.0-beta` < `1.0.0` < `1.0.1` < `1.1.0`
#### `version-date`
Accepts version strings that can be parsed to a date following the ISO-8601 format `YYYY-MM-DD`. Disambiguation identifiers are allowed in the form of dot-separated-, positive-, integer-numbers with no leading zeroes.
The regex pattern for this versioning scheme is: `\d{4}-\d{2}-\d{2}(\.(0|[1-9]\d*))*`
_Sorting behavior_: Strings are sorted first by their date part, then by numeric comparison of their disambiguation identifiers. Disambiguation identifiers follow the rules of the relaxed (`version`) scheme.
Examples:
`2021-01-01` < `2021-01-01.1` < `2021-02-01.1.2` < `2021-02-01.1.3` < `2021-02-01`
#### `version-string`
For packages using version strings that do not fit any of the other schemes, it accepts most arbitrary strings. The `#` which is used to denote port versions is disallowed.
_Sorting behavior_: No sorting is attempted on the version string itself. However, if the strings match exactly, their port versions can be compared and sorted.
Examples:
* `apple` <> `orange` <> `orange.2` <> `orange2`
* `watermelon#0`< `watermelon#1`
#### `port-version`
A positive integer value that increases each time a vcpkg-specific change is made to the port.
The rules for port versions are:
* Start at 0 for the original version of the port,
* increase by 1 each time a vcpkg-specific change is made to the port that does not increase the version of the package,
* and reset to 0 each time the version of the package is updated.
_NOTE: Whenever vcpkg output a version it follows the format `<version>#<port version>`. For example `1.2.0#2` means version `1.2.0` port version `2`. When the port version is `0` the `#0` suffix is omitted (`1.2.0` implies version `1.2.0` port version `0`)._
_Sorting behavior_: If two versions compare equally, their port versions are compared by their numeric value, lower port versions take precedence.
Examples:
* `1.2.0` < `1.2.0#1` < `1.2.0#2` < `1.2.0#10`
* `2021-01-01#20` < `2021-01-01.1`
* `windows#7` < `windows#8`
## Version files
Vcpkg uses a set of metadata files to power its versioning feature.
These files are located in the following locations:
* `${VCPKG_ROOT}/versions/baseline.json`, (this file is common to all ports) and
* `${VCPKG_ROOT}/versions/${first-letter-of-portname}-/${portname}.json` (one per port).
For example, for `zlib` the relevant files are:
* `${VCPKG_ROOT}/versions/baseline.json`
* `${VCPKG_ROOT}/versions/z-/zlib.json`
CI checks validate that each time a port is added or updated, its respective version files are also updated.
### Baseline file
The baseline file located in `${VCPKG_ROOT}/versions/baseline.json` is used to declared the current baseline versions of all packages.
A small section of the contents of this file is presented below:
```
{
"default": {
"3fd": { "baseline": "2.6.3", "port-version": 0 },
"7zip": { "baseline": "19.00", "port-version": 2 },
"abseil": { "baseline": "2020-09-23", "port-version": 1 }
...
}
}
```
Provided that there are no local modifications to the ports, the versions of all packages in the baseline file should map to the version of their corresponding portfiles in the `ports/` directory.
### Versions file
Each port in vcpkg has a corresponding versions file, the location of a port's versions file follows the pattern:
```
${VCPKG_ROOT}/versions/${first-letter-of-portname}-/${portname}.json
```
For example, for `zlib` the corresponding versions file is:
```
${VCPKG_ROOT}/versions/z-/zlib.json
```
These files contain an array of all the versions available for a given port.
For example, the contents of `versions/z-/zlib.json` declare the following versions:
```
{
"versions": [
{
"git-tree": "827111046e37c98153d9d82bb6fa4183b6d728e4",
"version-string": "1.2.11",
"port-version": 9
},
{
"git-tree": "068430e3e24fa228c302c808ba99f8a48d126557",
"version-string": "1.2.11",
"port-version": 8
},
...
]
}
```
Each version declared in this file uses the same syntax used in manifest files, but adds an extra `git-tree` property. The value of `git-tree` is the SHA hash, as calculated by Git, of the directory containing the portfiles for the declared version.
### Updating the version files
The recommended method to update these files is to run the `x-add-version` command.
For example, if you have made changes to `zlib`:
```
vcpkg x-add-version zlib
```
If you're updating multiple ports at the same time, instead you can run:
```
vcpkg x-add-version --all
```
To update the files for all modified ports at once.
_NOTE: These commands require you to have committed your changes to the ports before running them. The reason is that the Git SHA of the port directory is required in these version files. But don't worry, the `x-add-version` command will warn you if you have local changes that haven't been committed._
## Version constraints
### `builtin-baseline`
Accepts a Git commit ID. Vcpkg will try to find a baseline file in the given commit ID and use that to set the baseline versions (lower bound versions) of all declared dependencies.
When resolving version constraints for a package, vcpkg will look for a baseline version:
* First by looking at the baseline file in the given commit ID.
* If the given commit ID does not contain a baseline file, vcpkg will fallback to use the local baseline file instead.
* If there's no local baseline file, vcpkg will use the version currently available in the ports directory.
_NOTE: If a baseline file is found, but it does not contain an entry for the package, the vcpkg invocation will fail._
Example:
```
{
"name": "project",
"version": "1.0.0",
"dependencies": ["zlib", "fmt"],
"builtin-baseline":"9fd3bd594f41afb8747e20f6ac9619f26f333cbe"
}
```
Baselines can be used without any other version constraints to obtain behavior close to using "classic" mode.
### `version>=`
Expresses a minimum version requirement, `version>=` declarations put a lower boundary on the versions that can be used to satisfy a dependency.
Example:
```
{
"name": "project",
"version-semver": "1.0.0",
"dependencies": [
{ "name": "zlib", "version>=": "1.2.11#9" },
{ "name": "fmt", "version>=": "7.1.3" }
],
"builtin-baseline":"9fd3bd594f41afb8747e20f6ac9619f26f333cbe"
}
```
As part of a version constraint declaration, a port version can be specified by adding the suffix `#<port-veresion>`, in the previous example `1.2.11#9` refers to version `1.2.11` port version `9`.
### `overrides`
Declaring an override forces vcpkg to ignore all other version constraints, both top-level and transitive constraints, and use the version specified in the override. This is useful for pinning exact versions and for resolving version conflicts.
Overrides are declared as an array of package version declarations.
For an override to take effect, the overridden package must form part of the dependency graph. That means that a dependency must be declared either by the top-level manifest or be part of a transitive dependency.
```
{
"name": "project",
"version-semver": "1.0.0",
"dependencies": [
{ "name": "zlib", "version>=": "1.2.11#9" },
"fmt"
],
"builtin-baseline":"9fd3bd594f41afb8747e20f6ac9619f26f333cbe",
"overrides": [
{ "name": "fmt", "version": "6.0.0" }
]
}
```