Versionsverwaltungsreferenz
Mit der Versionsverwaltung können Sie die genauen Überarbeitungen von Abhängigkeiten, die von Ihrem Projekt in Ihrer Manifestdatei verwendet werden, deterministisch steuern. Die Versionsverwaltung ist nur für Benutzer im Manifestmodus verfügbar.
Weitere Informationen zum vcpkg-Versionsverwaltungsalgorithmus und allgemeinen Konzepten finden Sie unter Versionsverwaltungskonzepte.
Ein Beispiel mit Kontext finden Sie in unserem Leitfaden für die ersten Schritte mit der Versionsverwaltung.
Versionsschemas
Ports in vcpkg sollten versuchen, die Versionsverwaltungskonventionen zu befolgen, die von den Autoren des Pakets verwendet werden. Aus diesem Grund sollte beim Deklarieren der Version eines Pakets das entsprechende Schema verwendet werden.
Jedes Versionsverwaltungsschema definiert eigene Regeln für eine gültige Versionszeichenfolge und wichtiger ist die Regeln zum Sortieren von Versionen mithilfe desselben Schemas.
Die versionsverwaltungsschemas, die von vcpkg verstanden werden, sind:
| Manifesteigenschaft | Versionsverwaltungsschema |
|---|---|
version |
Für punkttrennte numerische Versionen |
version-semver |
Für SemVer-kompatible Versionen |
version-date |
Für Datumsangaben im Format YYYY-MM-DD |
version-string |
Für beliebige Zeichenfolgen |
Ein Manifest darf nur eine Versionsdeklaration enthalten.
Hinweis
Standardmäßig vergleicht vcpkg keine Versionen, die unterschiedliche Schemas verwenden. Beispielsweise kann ein Paket, das über ein version-string: 7.1.3 Paket verfügt, nicht mit demselben Paket version: 7.1.4verglichen werden, auch wenn die Konvertierung offensichtlich erscheint.
version
Akzeptiert Versionszeichenfolgen, die einem entspannten, punkttrennten, semverähnlichen Schema folgen.
Die Version besteht logisch aus punkttrennten (.) numerischen Abschnitten. Jeder Abschnitt muss eine ganzzahlige positive Zahl ohne führende Nullen enthalten.
Das regex-Muster für dieses Versionsverwaltungsschema lautet: (0|[1-9]\d*)(\.(0|[1-9]\d*))*
Sortierverhalten: Beim Vergleichen von zwei Versionen wird jeder Abschnitt von links nach rechts mit dem numerischen Wert verglichen, bis der erste Unterschied gefunden wird. Eine Version mit der kleinsten Gruppe von Abschnitten hat Vorrang vor einer anderen mit einer größeren Gruppe von Abschnitten, da alle vorherigen Abschnitte gleich vergleichen.
Beispiel:
0 < 0.1 < 0.1.0 < 1 < 1.0.0 < 1.0.1 < 1.1< 2.0.0
version-semver
Akzeptiert Versionszeichenfolgen, die den Konventionen für die semantische Versionsverwaltung folgen, wie in der Spezifikation für die semantische Versionsverwaltung beschrieben.
Sortierverhalten: Zeichenfolgen werden nach den regeln sortiert, die in der Semantikversionsspezifikation beschrieben sind.
Beispiel:
1.0.0-1 < 1.0.0-alpha < 1.0.0-beta < 1.0.0 < 1.0.1 < 1.1.0
version-date
Akzeptiert Versionszeichenfolgen, die nach dem ISO-8601-Format YYYY-MM-DDanalysiert werden können. Mehrdeutige Bezeichner sind in Form von punkttrennten, positiven, ganzzahligen Zahlen ohne führende Nullen zulässig.
Dies ist das empfohlene Versionsverwaltungsschema für "Live at HEAD"-Bibliotheken, die keine etablierten Versionsversionen haben.
Das regex-Muster für dieses Versionsverwaltungsschema lautet: \d{4}-\d{2}-\d{2}(\.(0|[1-9]\d*))*
Sortierverhalten: Zeichenfolgen werden zuerst nach ihrem Datumsteil und dann nach numerischem Vergleich ihrer Mehrdeutigkeitsbezeichner sortiert. Mehrdeutige Bezeichner folgen den Regeln des entspannten (version) Schemas.
Beispiele: 2021-01-01<2021-01-01.1<2021-02-01.1.2<2021-02-01.1.3<2021-02-01
version-string
Für Pakete, die Versionszeichenfolgen verwenden, die keines der anderen Schemas entsprechen, akzeptiert sie die meisten beliebigen Zeichenfolgen. Die # zum Kennzeichnen von Portversionen verwendete Version ist unzulässig.
Sortierverhalten: Für die Versionszeichenfolge selbst wird keine Sortierung versucht. Wenn die Zeichenfolgen jedoch exakt übereinstimmen, können ihre Portversionen verglichen und sortiert werden.
Beispiele:
apple<>orange<>orange.2<>orange2watermelon#0<watermelon#1
port-version
Portversionen verfolgen Änderungen in den Paketdateien (vcpkg.json, portfile.cmakeusw.) ohne Änderungen an der Upstream-Bibliotheksversion.
Eine Portversion ist ein nicht negativer ganzzahliger Wert.
Die Regeln für Portversionen sind:
- Beginnen Sie bei 0 für die ursprüngliche Version des Ports,
- wird jedes Mal um 1 erhöht, wenn eine vcpkg-spezifische Änderung an dem Port vorgenommen wird, der die Version des Pakets nicht erhöht,
- und jedes Mal, wenn die Version des Pakets aktualisiert wird, auf 0 zurückgesetzt.
Hinweis
vcpkg folgt dem Textformat <version>#<port version>. Beispiel 1.2.0#2 : Versionsportversion 1.2.02. Wenn die Portversion das Suffix ausgelassen 0 wird (z. B. 1.2.0 impliziert version portierte Version 1.2.00).#0
Sortierverhalten: Wenn zwei Versionen gleich vergleichen, werden ihre Portversionen mit ihrem numerischen Wert verglichen, niedrigere Portversionen haben Vorrang.
Beispiele:
1.2.0<1.2.0#1<1.2.0#2<1.2.0#102021-01-01#20<2021-01-01.1windows#7<windows#8
Versionsbeschränkungen
Basislinien
Basispläne definieren einen globalen Versionsboden für die Versionen, die berücksichtigt werden. Dadurch können Manifeste der obersten Ebene das gesamte Diagramm der Abhängigkeiten auf dem neuesten Stand halten, ohne dass sie direkte "version>=" Einschränkungen einzeln angeben müssen.
Jede konfigurierte Registrierung weist einen zugeordneten Basisplan auf. Für Manifeste, die keine Registrierungen konfigurieren, definiert das "builtin-baseline" Feld die Basislinie für die integrierte Registrierung. Wenn ein Manifest keine Registrierungen konfiguriert und keine "builtin-baseline"verfügt, wird die Installation gemäß dem Algorithmus für den klassischen Modus ausgeführt und ignoriert alle Versionsverwaltungsinformationen.
Baselines, wie andere Registrierungseinstellungen, werden von Ports ignoriert, die als Abhängigkeit verwendet werden. Wenn während der transitiven Versionsauflösung eine Mindestversion erforderlich ist, sollte der Port verwendet werden "version>=".
Beispiel
{
"name": "project",
"version": "1.0.0",
"dependencies": ["zlib", "fmt"],
"builtin-baseline":"9fd3bd594f41afb8747e20f6ac9619f26f333cbe"
}
Verwenden Sie zum Hinzufügen eines anfänglichen "builtin-baseline"Verwendungszwecks vcpkg x-update-baseline --add-initial-baseline. Verwenden Sie vcpkg x-update-baselinezum Aktualisieren von Basisplanen in einem Manifest .
version>=
Expresses a minimum version requirement, version>= declarations put a lower boundary on the versions that can be used to satisfy a dependency.
Hinweis
vcpkg wählt die niedrigste Version aus, die allen Einschränkungen entspricht, sodass keine Einschränkung kleiner als erforderlich ist.
Beispiel:
{
"name": "project",
"version-semver": "1.0.0",
"dependencies": [
{ "name": "zlib", "version>=": "1.2.11#9" },
{ "name": "fmt", "version>=": "7.1.3#1" }
],
"builtin-baseline":"3426db05b996481ca31e95fff3734cf23e0f51bc"
}
Als Teil einer Versionseinschränkungsdeklaration kann eine Portversion durch Hinzufügen des Suffixes #<port-version>angegeben werden, im vorherigen Beispiel 1.2.11#9 bezieht sich auf version 1.2.11 port version 9.
overrides
Durch das Deklarieren einer Außerkraftsetzung wird vcpkg gezwungen, alle anderen Versionseinschränkungen zu ignorieren und die in der Außerkraftsetzung angegebene Version zu verwenden. Dies ist nützlich zum Anheften exakter Versionen und zum Beheben von Versionskonflikten.
Außerkraftsetzungen werden als Array von Paketversionsdeklarationen deklariert.
Damit eine Außerkraftsetzung wirksam wird, muss das überschriebene Paket Teil des Abhängigkeitsdiagramm sein. Das bedeutet, dass eine Abhängigkeit entweder durch das Manifest der obersten Ebene deklariert oder Teil einer transitiven Abhängigkeit sein muss.
{
"name": "project",
"version-semver": "1.0.0",
"dependencies": [
"curl",
{ "name": "zlib", "version>=": "1.2.11#9" },
"fmt"
],
"builtin-baseline":"3426db05b996481ca31e95fff3734cf23e0f51bc",
"overrides": [
{ "name": "fmt", "version": "6.0.0" },
{ "name": "openssl", "version": "1.1.1h#3" }
]
}
