Referencia de control de versiones

El control de versiones permite controlar de forma determinista las revisiones precisas de las dependencias usadas por el proyecto desde el archivo de manifiesto. El control de versiones solo está disponible para los usuarios del modo manifiesto.

Para obtener más información sobre el algoritmo de control de versiones de vcpkg y los conceptos de alto nivel, consulte Conceptos de control de versiones.

Para obtener un ejemplo con contexto, consulte nuestra guía para empezar a trabajar con el control de versiones.

Esquemas de versión

Los puertos de vcpkg deben intentar seguir las convenciones de control de versiones usadas por los autores del paquete. Por ese motivo, al declarar la versión de un paquete, se debe usar el esquema adecuado.

Cada esquema de control de versiones define sus propias reglas sobre lo que es una cadena de versión válida y, más importante, las reglas para ordenar versiones con el mismo esquema.

Los esquemas de control de versiones comprendidos por vcpkg son:

Propiedad de manifiesto	Esquema de control de versiones
version	Para versiones numéricas separadas por puntos
version-semver	Para versiones compatibles con SemVer
version-date	Para las fechas con el formato YYYY-MM-DD
version-string	Para cadenas arbitrarias

Un manifiesto solo debe contener una declaración de versión.

Nota:

Por diseño, vcpkg no compara versiones que usan esquemas diferentes. Por ejemplo, un paquete que tiene un version-string: 7.1.3 no se puede comparar con el mismo paquete mediante version: 7.1.4, incluso si la conversión parece obvia.

version

Acepta cadenas de versión que siguen un esquema relajado, separado por puntos, similar a semver.

La versión se compone lógicamente de secciones numéricas separadas por puntos (.). Cada sección debe contener un número positivo entero sin ceros iniciales.

El patrón regex para este esquema de control de versiones es: (0|[1-9]\d*)(\.(0|[1-9]\d*))*

Comportamiento de ordenación: al comparar dos versiones, cada sección se compara de izquierda a derecha por su valor numérico, hasta que se encuentra la primera diferencia. Una versión con el conjunto más pequeño de secciones tiene prioridad sobre otra con un conjunto mayor de secciones, dado que todas sus secciones anteriores se comparan de forma equitativa.

Ejemplo:

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

version-semver

Acepta cadenas de versión que siguen las convenciones de control de versiones semánticas, como se describe en la especificación de control de versiones semántica.

Comportamiento de ordenación: las cadenas se ordenan siguiendo las reglas descritas en la especificación de control de versiones semántica.

Ejemplo:

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

version-date

Acepta cadenas de versión que se pueden analizar en una fecha siguiendo el formato YYYY-MM-DDISO-8601 . Los identificadores de desambiguación se permiten en forma de números enteros separados por puntos, positivos y enteros sin ceros iniciales.

Este es el esquema de control de versiones recomendado para las bibliotecas "Live at HEAD" que no tienen versiones de versión establecidas.

El patrón regex para este esquema de control de versiones es: \d{4}-\d{2}-\d{2}(\.(0|[1-9]\d*))*

Comportamiento de ordenación: las cadenas se ordenan primero por su parte de fecha y, a continuación, por comparación numérica de sus identificadores de desambiguación. Los identificadores de desambiguación siguen las reglas del esquema relajado (version).

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

version-string

En el caso de los paquetes que usan cadenas de versión que no se ajustan a ninguno de los otros esquemas, acepta la mayoría de las cadenas arbitrarias. No # se permite el que se usa para indicar versiones de puerto.

Comportamiento de ordenación: no se intenta ordenar en la propia cadena de versión. Sin embargo, si las cadenas coinciden exactamente, sus versiones de puerto se pueden comparar y ordenar.

Ejemplos:

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

port-version

Las versiones de puerto realizan un seguimiento de los cambios en los archivos de empaquetado (vcpkg.json, portfile.cmake, etc.) sin cambios en la versión de la biblioteca ascendente.

Una versión del puerto es un valor entero no negativo.

Las reglas para las versiones de puerto son:

• Comience en 0 para la versión original del puerto,
• aumentar en 1 cada vez que se realiza un cambio específico de vcpkg en el puerto que no aumenta la versión del paquete,
• y restablezca a 0 cada vez que se actualice la versión del paquete.

Nota:

vcpkg sigue el formato <version>#<port version>de texto . Por ejemplo, 1.2.0#2 significa versión del puerto de versión 1.2.02. Si la versión del puerto es 0 el sufijo se omite (por ejemplo, 1.2.0 implica la versión del puerto de versión 1.2.00).#0

Comportamiento de ordenación: si dos versiones se comparan igual, sus versiones de puerto se comparan por su valor numérico, las versiones de puerto inferiores tienen prioridad.

Ejemplos:

• 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

Restricciones de versión

Líneas de base

Las líneas base definen un piso de versión global para qué versiones se considerarán. Esto permite que los manifiestos de nivel superior mantengan actualizado todo el gráfico de dependencias sin necesidad de especificar individualmente restricciones directas "version>=" .

Cada registro configurado tiene una línea base asociada. En el caso de los manifiestos que no configuran ningún registro, el "builtin-baseline" campo define la línea base para el registro integrado. Si un manifiesto no configura ningún registro y no tiene un "builtin-baseline", la instalación funciona según el algoritmo de modo clásico y omite toda la información de control de versiones.

Las líneas base, al igual que otras configuraciones del Registro, se omiten de los puertos consumidos como dependencia. Si se requiere una versión mínima durante la resolución de versiones transitivas, el puerto debe usar "version>=".

Ejemplo

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

Para agregar una inicial "builtin-baseline", use vcpkg x-update-baseline --add-initial-baseline. Para actualizar las líneas base de un manifiesto, use vcpkg x-update-baseline.

version>=

Expresa un requisito mínimo de versión, version>= las declaraciones colocan un límite inferior en las versiones que se pueden usar para satisfacer una dependencia.

Nota:

vcpkg selecciona la versión más baja que coincide con todas las restricciones, por lo que no se requiere una restricción menor que.

Ejemplo:

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

Como parte de una declaración de restricción de versión, se puede especificar una versión del puerto agregando el sufijo #<port-version>, en el ejemplo 1.2.11#9 anterior se refiere a la versión del puerto de versión 1.2.119.

overrides

Declarar una invalidación obliga a vcpkg a omitir todas las demás restricciones de versión y usar la versión especificada en la invalidación. Esto resulta útil para anclar versiones exactas y para resolver conflictos de versiones.

Las invalidaciones se declaran como una matriz de declaraciones de versión de paquete.

Para que una invalidación surta efecto, el paquete invalidado debe formar parte del gráfico de dependencias. Esto significa que el manifiesto de nivel superior debe declarar una dependencia o formar parte de una dependencia transitiva.

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