版本管理简介¶
到目前为止，我们一直使用固定版本的 requires，例如 requires = "zlib/1.2.12"。但有时依赖项会发展，新版本会发布，消费者希望尽可能轻松地更新到这些版本。
总是可以编辑 conanfiles 并显式地将版本更新为新的版本，但在 Conan 中有一些机制允许在不修改 recipes 的情况下进行此类更新。
版本范围¶
一个 requires 可以使用 pkgname/[version-range-expression] 的语法，来表达对给定包的某个版本范围的依赖。让我们看一个例子。请先克隆源代码以重新创建此项目。您可以在 GitHub 上的 examples2 仓库 中找到它们。
$ git clone https://github.com/conan-io/examples2.git
$ cd examples2/tutorial/consuming_packages/versioning
我们可以看到，我们在这里有
from conan import ConanFile
class CompressorRecipe(ConanFile):
settings = "os", "compiler", "build_type", "arch"
generators = "CMakeToolchain", "CMakeDeps"
def requirements(self):
self.requires("zlib/[~1.2]")
那个 requires 包含表达式 zlib/[~1.2]，它的意思是“大约” 1.2 版本。也就是说，它可以解析为任何 zlib/1.2.8、zlib/1.2.11 或 zlib/1.2.12，但它不会解析为像 zlib/1.3.0 这样的版本。在可用的匹配版本中，版本范围将始终选择最新的一个。
如果我们运行 conan install，我们将看到类似如下的内容
$ conan install .
Graph root
conanfile.py: .../conanfile.py
Requirements
zlib/1.2.12#87a7211557b6690ef5bf7fc599dd8349 - Downloaded
Resolved version ranges
zlib/[~1.2]: zlib/1.2.12
如果我们尝试改用 zlib/[<1.2.12]，这意味着我们想使用低于 1.2.12 的版本，但那个版本被排除了，所以满足该范围的最新版本将是 zlib/1.2.11。
$ conan install .
Resolved version ranges
zlib/[<1.2.12]: zlib/1.2.11
同样适用于其他类型的 requirements，例如 tool_requires。让我们在 recipe 中添加一个。
from conan import ConanFile
class CompressorRecipe(ConanFile):
settings = "os", "compiler", "build_type", "arch"
generators = "CMakeToolchain", "CMakeDeps"
def requirements(self):
self.requires("zlib/[~1.2]")
def build_requirements(self):
self.tool_requires("cmake/[>3.10]")
我们看到它解析到了最新的可用 CMake 包，版本至少为 3.11。
$ conan install .
...
Graph root
conanfile.py: .../conanfile.py
Requirements
zlib/1.2.12#87a7211557b6690ef5bf7fc599dd8349 - Cache
Build requirements
cmake/3.27.9#f305019023c2db74d1001c5afa5cf362 - Downloaded
Resolved version ranges
cmake/[>3.10]: cmake/3.27.9
zlib/[~1.2]: zlib/1.2.12
修订版本¶
当包的创建者对包的 recipe 或源代码进行一些更改，但没有增加 version 来反映这些更改时，会发生什么？Conan 有一个内部机制来跟踪这些修改，它被称为 **修订版本 (revisions)**。
Recipe 修订版本是与包名称和版本一起显示的哈希值，形式为 pkgname/version#recipe_revision 或 pkgname/version@user/channel#recipe_revision。Recipe 修订版本是 recipe 内容和源代码的哈希。因此，如果 recipe、其相关文件或该 recipe 打包的源代码中的任何内容发生更改，它将创建一个新的 recipe 修订版本。
您可以使用 conan list 命令列出已有的修订版本。
$ conan list "zlib/1.2.12#*" -r=conancenter
conancenter
zlib
zlib/1.2.12
revisions
82202701ea360c0863f1db5008067122 (2022-03-29 15:47:45 UTC)
bd533fb124387a214816ab72c8d1df28 (2022-05-09 06:59:58 UTC)
3b9e037ae1c615d045a06c67d88491ae (2022-05-13 13:55:39 UTC)
...
修订版本总是解析到最新的（按创建或上传到服务器的顺序）修订版本。虽然这不是常见的做法，但可以直接在 conanfile 中固定一个给定的 recipe 修订版本，例如：
def requirements(self):
self.requires("zlib/1.2.12#87a7211557b6690ef5bf7fc599dd8349")
但是，当创建新的修订版本时，这种机制可能会很麻烦，难以维护和更新，所以在一般情况下，不应该这样做。
锁定文件¶
版本范围的使用，以及在不增加版本号的情况下创建给定包的新修订版本的可能性，允许进行快速、自动和方便的更新，而无需编辑 recipes。
但在某些情况下，也有必要提供一个不可变的、可重现的依赖项集。这个过程被称为“锁定”，允许它的机制是“锁文件 (lockfile)”文件。锁文件是一个包含固定依赖项列表的文件，指定确切的版本和确切的修订版本。因此，例如，锁文件将永远不会包含带有表达式的版本范围，而只包含固定的依赖项。
锁文件可以看作是某个时间点的依赖图的快照。这样的快照必须是“可实现的”，也就是说，它必须是从 conanfile recipes 中实际可重现的状态。并且可以在以后使用此锁文件强制执行相同的状态，即使有新创建的包版本。
让我们看看锁文件是如何工作的。首先，让我们将示例中的依赖项固定到 zlib/1.2.11。
def requirements(self):
self.requires("zlib/1.2.11")
然后，让我们捕获一个锁文件。
conan lock create .
-------- Computing dependency graph ----------
Graph root
conanfile.py: .../conanfile.py
Requirements
zlib/1.2.11#4524fcdd41f33e8df88ece6e755a5dcc - Cache
Generated lockfile: .../conan.lock
让我们看看 conan.lock 文件包含什么。
{
"version": "0.5",
"requires": [
"zlib/1.2.11#4524fcdd41f33e8df88ece6e755a5dcc%1650538915.154"
],
"build_requires": [],
"python_requires": []
}
现在，让我们恢复原始的 requires 版本范围。
def requirements(self):
self.requires("zlib/[~1.2]")
并运行 conan install .，它默认会找到 conan.lock，并运行等效的 conan install . --lockfile=conan.lock。
conan install .
Graph root
conanfile.py: .../conanfile.py
Requirements
zlib/1.2.11#4524fcdd41f33e8df88ece6e755a5dcc - Cache
请注意，版本范围不再被解析，并且它不会获取 zlib/1.2.12 依赖项，即使它在允许的范围 zlib/[~1.2] 内，因为 conan.lock 锁文件强制它保持在 zlib/1.2.11 以及确切的修订版本。