Naslaginformatie over versiebeheer

Met versiebeheer kunt u deterministische controle houden over de exacte revisies van afhankelijkheden die door uw project worden gebruikt vanuit uw manifestbestand. Versiebeheer is alleen beschikbaar voor manifestmodus gebruikers.

Zie Versiebeheerconceptenvoor meer informatie over het vcpkg-versiebeheeralgoritmen en concepten op hoog niveau.

Zie onze handleiding voor aan de slag met versiebeheervoor een voorbeeld met context.

Versieschema's

Poorten in vcpkg moeten proberen de versieconventies te volgen die door de auteurs van het pakket worden gebruikt. Daarom moet bij het declareren van de versie van een pakket het juiste schema worden gebruikt.

Elk versiebeheerschema definieert zijn eigen regels voor wat een geldige versietekenreeks is en belangrijker de regels voor het sorteren van versies met hetzelfde schema.

De versiebeheerschema's die door vcpkg worden begrepen, zijn:

Manifesteigenschap	Versiebeheerschema
version	Voor door punt gescheiden numerieke versies
version-semver	Voor versies die compatibel zijn met SemVer
version-date	Voor datums in de notatie YYYY-MM-DD
version-string	Voor willekeurige tekenreeksen

Een manifest mag slechts één versiedeclaratie bevatten.

Notitie

Vcpkg vergelijkt standaard geen versies die gebruikmaken van verschillende schema's. Een pakket met een version-string: 7.1.3 kan bijvoorbeeld niet worden vergeleken met hetzelfde pakket met behulp van version: 7.1.4, zelfs als de conversie duidelijk lijkt.

version

Accepteert versietekenreeksen die een ontspannen, door punt gescheiden, semver-achtig schema volgen.

De versie bestaat logisch uit puntscheidingstekens (.) numerieke secties. Elke sectie moet een positief geheel getal zonder voorloopnullen bevatten.

Het regex-patroon voor dit versiebeheerschema is: (0|[1-9]\d*)(\.(0|[1-9]\d*))*

sorteergedrag: bij het vergelijken van twee versies wordt elke sectie vergeleken van links naar rechts met de numerieke waarde totdat het eerste verschil wordt gevonden. Een versie met de kleinste set secties heeft voorrang op een andere met een grotere set secties, aangezien alle voorgaande secties gelijk worden vergeleken.

Voorbeeld:

0 < 0.1 < 0.1.0 < 1 < 1.0.0 < 1.0.1 < 1.1< 2.0.0

version-semver

Accepteert versietekenreeksen die voldoen aan de semantische versieconventies, zoals beschreven in de semantische versiebeheerspecificatie.

Sorteergedrag: Tekenreeksen worden gesorteerd volgens de regels die worden beschreven in de semantische versiebeheerspecificatie.

Voorbeeld:

1.0.0-1 < 1.0.0-alpha < 1.0.0-beta < 1.0.0 < 1.0.1 < 1.1.0

version-date

Accepteert versietekenreeksen die kunnen worden geparseerd tot een datum na de ISO-8601-indeling YYYY-MM-DD. Ondubbelzinnige id's zijn toegestaan in de vorm van door punt gescheiden, positieve, gehele getallen zonder voorloopnullen.

Dit is het aanbevolen versiebeheerschema voor 'Live at HEAD'-bibliotheken die geen releaseversies hebben.

Het regex-patroon voor dit versiebeheerschema is: \d{4}-\d{2}-\d{2}(\.(0|[1-9]\d*))*

Sorteergedrag: Tekenreeksen worden eerst gesorteerd op het datumgedeelte en vervolgens op numerieke vergelijking van hun ondubbelzinnige id's. De ondubbelzinnigheidsaanduidingen volgen de regels van het ontspannen (version) schema.

Voorbeelden: 2021-01-01<2021-01-01.1<2021-02-01.1.2<2021-02-01.1.3<2021-02-01

version-string

Voor pakketten die gebruikmaken van versietekenreeksen die niet in een van de andere schema's passen, worden de meeste willekeurige tekenreeksen geaccepteerd. De # die wordt gebruikt om poortversies aan te geven, is niet toegestaan.

sorteergedrag: er wordt geen sortering uitgevoerd op de versietekenreeks zelf. Als de tekenreeksen echter exact overeenkomen, kunnen hun poortversies worden vergeleken en gesorteerd.

Voorbeelden:

• apple <> orange <> orange.2 <> orange2
• watermelon#0< watermelon#1

port-version

Port-versions volgen wijzigingen in de verpakkingsbestanden (vcpkg.json, portfile.cmake, enzovoort) zonder wijzigingen in de upstream-bibliotheekversie.

Een poortversie is een niet-negatieve geheel getalwaarde.

De regels voor poortversies zijn:

• Begin bij 0 voor de oorspronkelijke versie van de poort,
• verhogen met 1 telkens wanneer een vcpkg-specifieke wijziging wordt aangebracht in de poort die de versie van het pakket niet verhoogt,
• en stel deze opnieuw in op 0 telkens wanneer de versie van het pakket wordt bijgewerkt.

Notitie

vcpkg volgt de tekstopmaak <version>#<port version>. 1.2.0#2 betekent bijvoorbeeld versie 1.2.0 poortversie 2. Als de poortversie wordt 0 wordt het achtervoegsel #0 weggelaten (bijvoorbeeld 1.2.0 impliceert versie 1.2.0 poortversie 0).

Sorteergedrag: als twee versies even vergelijken, worden de poortversies vergeleken met hun numerieke waarde, hebben lagere poortversies voorrang.

Voorbeelden:

• 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

Versiebeperkingen

Basislijnen

Basislijnen definiëren een algemene versievloer voor welke versies worden overwogen (tenzij elders is opgegeven, wordt de versie die aan die basislijn is gekoppeld, gebruikt). Hierdoor kunnen manifesten op het hoogste niveau de hele grafiek van afhankelijkheden up-to-date houden zonder dat u afzonderlijke directe "version>=" beperkingen hoeft op te geven.

Elk geconfigureerd register heeft een gekoppelde basislijn. Voor manifesten die geen registers configureren, definieert het veld "builtin-baseline" de basislijn voor het ingebouwde register. Als een manifest geen registers configureert en geen "builtin-baseline"heeft, werkt de installatie volgens het algoritme van de klassieke modus en worden alle versiegegevens genegeerd.

Basislijnen, zoals andere registerinstellingen, worden genegeerd van poorten die worden gebruikt als een afhankelijkheid. Als er een minimale versie is vereist tijdens de transitieve versieomzetting, moet de poort "version>="gebruiken.

Voorbeeld

{
  "name": "project",
  "version": "1.0.0",
  "dependencies": ["zlib", "fmt"],
  "builtin-baseline":"9fd3bd594f41afb8747e20f6ac9619f26f333cbe"
}

Als u een eerste "builtin-baseline"wilt toevoegen, gebruikt u vcpkg x-update-baseline --add-initial-baseline. Als u basislijnen in een manifest wilt bijwerken, gebruikt u vcpkg x-update-baseline.

version>=

Geeft een minimale versievereiste aan, version>= declaraties een ondergrens stellen voor de versies die kunnen worden gebruikt om te voldoen aan een afhankelijkheid.

Notitie

vcpkg selecteert de laagste versie die overeenkomt met alle beperkingen, dus een beperking die kleiner is dan is niet vereist.

Voorbeeld:

{
  "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 onderdeel van een versiebeperkingsdeclaratie kan een poortversie worden opgegeven door het achtervoegsel #<port-version>toe te voegen. In het vorige voorbeeld verwijst 1.2.11#9 naar versie 1.2.11 poortversie 9.

overrides

Als u een onderdrukking declareren, wordt vcpkg gedwongen alle andere versiebeperkingen te negeren en de versie te gebruiken die is opgegeven in de onderdrukking. Dit is handig voor het vastmaken van exacte versies en voor het oplossen van versieconflicten.

Onderdrukkingen worden gedeclareerd als een matrix met declaraties van pakketversies.

Om een onderdrukking van kracht te laten worden, moet het overschreven pakket deel uitmaken van de afhankelijkheidsgrafiek. Dit betekent dat een afhankelijkheid moet worden gedeclareerd door het manifest op het hoogste niveau of deel uitmaakt van een transitieve afhankelijkheid.

Slechts één onderdrukking kan worden gedeclareerd voor een bepaalde naam.

{
  "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" }
  ]
}