バージョン管理リファレンス

バージョン管理を使用すると、マニフェスト ファイル内からプロジェクトで使用される依存関係の正確なリビジョンを決定論的に制御できます。 バージョン管理は、マニフェスト モードのユーザーのみが使用できます。

vcpkg バージョン管理アルゴリズムと高度な概念の詳細については、「バージョン管理の概念」を参照してください。

コンテキストの例については、バージョン管理の概要に関する ガイドを参照してください。

バージョン スキーム

vcpkg のポートは、パッケージの作成者が使用するバージョン管理規則に従うように試みる必要があります。 そのため、パッケージのバージョンを宣言するときは、適切なスキームを使用する必要があります。

各バージョン管理スキームでは、有効なバージョン文字列とは何か、さらに重要なのは、同じスキームを使用してバージョンを並べ替える方法に関する規則に関する独自の規則を定義します。

vcpkg によって認識されるバージョン管理スキームは次のとおりです。

マニフェスト プロパティ	バージョン管理スキーム
version	ドット区切りの数値バージョンの場合
version-semver	SemVer 準拠バージョンの場合
version-date	形式の日付の場合 YYYY-MM-DD
version-string	任意の文字列の場合

マニフェストには、バージョン宣言を 1 つだけ含む必要があります。

Note

設計上、vcpkg は異なるスキームを使用するバージョンを比較しません。 たとえば、あるパッケージを version-string: 7.1.3 使用して version: 7.1.4同じパッケージと比較することはできません。変換が明白な場合でも、

version

緩やかなドット区切り、semver のようなスキームに従うバージョン文字列を受け入れます。

このバージョンは、論理的にはドット区切り (.) の数値セクションで構成されます。 各セクションには、先行ゼロのない正の整数を含む必要があります。

このバージョン管理スキームの正規表現パターンは次のとおりです。 (0|[1-9]\d*)(\.(0|[1-9]\d*))*

並べ替え動作: 2 つのバージョンを比較する場合、各セクションは、最初の差が見つかるまで、数値によって左から右に比較されます。 セクションのセットが最も小さいバージョンは、前のすべてのセクションが等しく比較されることを考えると、より大きなセクションセットを持つ別のセクションよりも優先されます。

例:

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

version-semver

セマンティック バージョン管理の仕様で説明されているように、セマンティック バージョン管理規則に従うバージョン文字列を受け入れます。

並べ替え動作: 文字列は、セマンティック バージョン管理の仕様で説明されている規則に従って並べ替えられます。

例:

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

version-date

ISO-8601 形式 YYYY-MM-DDの後の日付に解析できるバージョン文字列を受け入れます。 あいまいさを解消する識別子は、ドット区切り、正、整数の形式で、先頭にゼロを付けることはできません。

これは、リリース バージョンが確立されていない "Live at HEAD" ライブラリに推奨されるバージョン管理スキームです。

このバージョン管理スキームの正規表現パターンは次のとおりです。 \d{4}-\d{2}-\d{2}(\.(0|[1-9]\d*))*

並べ替え動作: 文字列は、最初に日付部分で並べ替えられた後、あいまいさを解消する識別子の数値比較によって並べ替えられます。 あいまいさを解消する識別子は、緩和された (version) スキームの規則に従います。

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

version-string

他のどのスキームにも適合しないバージョン文字列を使用するパッケージの場合、ほとんどの任意の文字列を受け入れます。 #ポートバージョンを示すために使用されるバージョンは許可されていません。

並べ替え動作: バージョン文字列自体に対して並べ替えが試行されません。 ただし、文字列が正確に一致する場合は、それらのポート バージョンを比較および並べ替えることができます。

例 :

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

port-version

ポート バージョンでは、アップストリーム ライブラリ バージョンに変更を加えることなく、portfile.cmakeパッケージ 化ファイル (vcpkg.jsonなど) の変更を追跡します。

ポート バージョンは負以外の整数値です。

ポート バージョンの規則は次のとおりです。

• ポートの元のバージョンでは 0 から開始します。
• パッケージのバージョンを増やさないポートに対して vcpkg 固有の変更が行われるたびに、1 ずつ増加します。
• を選択し、パッケージのバージョンが更新されるたびに 0 にリセットします。

Note

vcpkg はテキスト形式 <version>#<port version>に従います。 たとえば、1.2.0#2バージョン ポートのバージョン21.2.0を意味します。 ポートのバージョンがサフィックスである#0場合は0省略されます (たとえば、1.2.0バージョン1.2.0ポートのバージョン0を意味します)。

並べ替え動作: 2 つのバージョンが等しく比較される場合、それらのポート バージョンは数値で比較され、下位のポート バージョンが優先されます。

例 :

• 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>=" 制約を個別に指定しなくても、依存関係のグラフ全体を最新の状態に保つことができます。

すべての構成済みレジストリには、ベースラインが関連付けられています。 レジストリを構成しないマニフェストの場合、 "builtin-baseline" フィールドは組み込みレジストリのベースラインを定義します。 マニフェストでレジストリが構成されておらず、レジストリがない "builtin-baseline"場合、インストールはクラシック モード アルゴリズムに従って動作し、すべてのバージョン管理情報を無視します。

他のレジストリ設定と同様に、ベースラインは依存関係として使用されるポートからは無視されます。 推移的なバージョン解決中に最小バージョンが必要な場合は、ポートで使用 "version>="する必要があります。

例

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

イニシャル "builtin-baseline"を追加するには、次を使用します vcpkg x-update-baseline --add-initial-baseline。 マニフェスト内のベースラインを更新するには、次を使用します vcpkg x-update-baseline。

version>=

最小バージョン要件を表します。宣言では、 version>= 依存関係を満たすために使用できるバージョンの境界が低くなります。

Note

vcpkg では、すべての制約に一致する最小バージョンが選択されるため、より小さい制約は必要ありません。

例:

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

バージョン制約宣言の一部として、前の例1.2.11#9ではバージョン ポート バージョンを参照するサフィックス#<port-version>を追加することで、ポート バージョン1.2.119を指定できます。

overrides

オーバーライドを宣言すると、vcpkg は他のすべてのバージョン制約を無視し、オーバーライドで指定されたバージョンを使用するように強制されます。 これは、正確なバージョンをピン留めしたり、バージョンの競合を解決したりするのに役立ちます。

オーバーライドは、パッケージ バージョン宣言の配列として宣言されます。

オーバーライドを有効にするには、オーバーライドされたパッケージが依存関係グラフの一部を形成する必要があります。 つまり、依存関係は、最上位レベルのマニフェストによって宣言するか、推移的な依存関係の一部である必要があります。

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