次の方法で共有

バージョン管理の概念

  • [アーティクル]

最小バージョン管理

vcpkg では、Go で使用されたものに着想を得て、バージョン管理に最小限の選択アプローチを使用しますが、いくつかの方法で変更されています。

  • 常に新しいインストールから開始されるため、アップグレード/ダウングレード操作は不要です。
  • ベースラインを導入することで、制約のない依存関係を許可します。

ただし、最小限の選択原則は同じままです。 一連の制約がある場合、vcpkg はすべての制約を満たすことができるパッケージの "最も古い" バージョンを使用します。

最小バージョンのアプローチを使用すると、次の利点があります。

  • 予測可能で、理解しやすいです。
  • アップグレードがいつ行われるかはユーザーが制御します。アップグレードは、新しいバージョンがリリースされたときに自動的に実行されません。
  • SAT ソルバーの使用を回避します。

例を示すには、次のパッケージ グラフを考えてみましょう。

    (A 1.0) -> (B 1.0)

    (A 1.1) -> (B 1.0) 
            -> (C 3.0) 

    (A 1.2) -> (B 2.0)
            -> (C 3.0)

    (C 2.0)

そして、次のマニフェスト:

{
    "name": "example",
    "version": "1.0.0",
    "dependencies": [ 
        { "name": "A", "version>=": "1.1" },
        { "name": "C", "version>=": "2.0" }
    ], 
    "builtin-baseline": "<some git commit with A's baseline at 1.0>"
}

推移的な依存関係を計算した後、次の一連の制約があります。

  • A >= 1.1
    • B >= 1.0
    • C >= 3.0
  • C >= 2.0

vcpkg はすべての制約を満たす必要があるため、インストールされているパッケージのセットは次のようになります。

  • A 1.1が存在する場合 A 1.2 でも、vcpkg が可能な最小バージョンを選択するよりも 1.1 高い制約はありません。
  • B 1.0で推移的に要求されます A 1.1。
  • C 3.0は、バージョンの制約を満たすために追加された推移的制約によって B 1.0 アップグレードされます。

制約の解決

一連のバージョン管理された依存関係を持つマニフェストを指定すると、vcpkg はすべての制約を満たすパッケージ インストール プランの計算を試みます。

バージョンの制約には、次の種類があります。

  • 宣言された制約: を使用してversion>=最上位のマニフェストで明示的に宣言された制約。
  • ベースライン制約: 制約が暗黙的に追加されます。builtin-baseline
  • 推移的制約: 依存関係の依存関係によって間接的に追加された制約。
  • オーバーライドされた制約: 宣言を使用してoverrides最上位レベルのマニフェストでオーバーライドされた制約。

インストール 計画を計算するために、vcpkg は大まかに次の手順に従います。

  • すべての最上位レベルの制約をプランに追加します。
  • 推移的な制約を計画に再帰的に追加します。
    • 新しいパッケージがプランに追加されるたびに、そのベースライン制約もプランに追加します。
    • 制約が追加されるたびに、
    • パッケージのオーバーライドが存在する場合
      • オーバーライドでバージョンを選択します。
    • それ以外の場合:
      • 以前のバージョンが選択されていない場合。
        • 制約を満たす最小バージョンを選択します。
      • 以前のバージョンが選択されている場合:
        • 新しい制約のバージョン管理スキームが、以前に選択したバージョンのバージョンと一致しない場合:
          • バージョンの競合を追加します。
        • 制約のバージョンが、以前に選択したバージョンと比較できない場合。 たとえば、"version-string: apple" と "version-string: orange" を比較します。
          • バージョンの競合を追加します。
        • 制約のバージョンが以前に選択したバージョンより高い場合:
          • 最も高いバージョンを選択します。
        • それ以外の場合:
          • 前の選択を維持します。
  • プランを確認します。
    • 競合がない場合
      • 選択したパッケージをインストールする
    • それ以外の場合:
      • 競合をユーザーに報告する

ポート バージョンの取得

パッケージ バージョンの概念は常に vcpkg に存在しますが、バージョン制約の概念は存在していません。

バージョン管理の制約が導入されたので、パッケージがローカルで使用可能なポート バージョンと一致しないポート バージョンに依存する可能性があります。 これにより、vcpkg が要求されたバージョンのポート ファイルを取得する方法を知る必要がある場合に問題が発生します。

この問題を解決するために、メタデータ ファイルの新しいセットが導入されました。 これらのファイルは、 versions/ vcpkg リポジトリのルート レベルのディレクトリにあります。

ディレクトリには versions/ 、レジストリで使用可能なポートごとに JSON ファイルが含まれます。 各ファイルには、パッケージで使用可能なすべてのバージョンが一覧表示され、vcpkg がそのバージョンのポートファイルを取得するためにチェックできる Git tree-ish オブジェクトが含まれます。

例: zlib.json

{
  "versions": [
    {
      "git-tree": "2dfc991c739ab9f2605c2ad91a58a7982eb15687",
      "version-string": "1.2.11",
      "port-version": 9
    },
    ...
    {
      "git-tree": "a516e5ee220c8250f21821077d0e3dd517f02631",
      "version-string": "1.2.10",
      "port-version": 0
    },
    {
      "git-tree": "3309ec82cd96d752ff890c441cb20ef49b52bf94",
      "version-string": "1.2.8",
      "port-version": 0
    }
  ]
}

ポートごとに、対応するバージョンファイルが .versions/{first letter of port name}-/{port name}.json たとえば、zlib のバージョン ファイルは versions/z-/zlib.json. ポート バージョン ファイルとは別に、現在のベースライン ファイルは versions/baseline.json.