版本范围¶

在上一节中，我们最终得到了 pkg 包的几个版本。让我们删除它们并创建以下简单的项目

pkg/conanfile.py¶

from conan import ConanFile

class pkgRecipe(ConanFile):
    name = "pkg"

app/conanfile.py¶

from conan import ConanFile

class appRecipe(ConanFile):
    name = "app"
    requires = "pkg/1.0"

让我们创建 pkg/1.0 并安装 app，看看它需要 pkg/1.0

$ conan remove "pkg*" -c
$ conan create pkg --version=1.0
... pkg/1.0 ...
$ conan install app
...
Requirements
    pkg/1.0

然后，如果我们创建 pkg/1.1 的新版本，它不会自动被 app 使用

$ conan create pkg --version=1.1
... pkg/1.0 ...
# Note how this still uses the previous 1.0 version
$ conan install app
...
Requirements
    pkg/1.0

因此，我们可以修改 app 的 conanfile 以显式使用新的 pkg/1.1 版本，但我们不这样做，而是使用以下版本范围表达式（由 [expression] 括号引入）

app/conanfile.py¶

from conan import ConanFile

class appRecipe(ConanFile):
    name = "app"
    requires = "pkg/[>=1.0 <2.0]"

当我们现在安装 app 的依赖项时，它会自动使用该范围内的最新版本，即使我们创建了一个新版本，而无需修改 app 的 conanfile

# this will now use the newer 1.1
$ conan install app
...
Requirements
    pkg/1.1

$ conan create pkg --version=1.2
... pkg/1.2 ...
# Now it will automatically use the newest 1.2
$ conan install app
...
Requirements
    pkg/1.2

只要新版本在定义的范围内，就会这样，如果我们创建一个 pkg/2.0 版本，app 将不会使用它

$ conan create pkg --version=2.0
... pkg/2.0 ...
# Conan will use the latest in the range
$ conan install app
...
Requirements
    pkg/1.2

当使用版本范围时，缓存中的版本优先于远程版本，因此如果您有一个本地的 pkg/1.2 包，它将被使用，而不是远程的包，即使远程的包是较新的。为了确保您使用最新的可用版本，您可以在 install/create 命令中使用 --update 参数。请注意，--update 参数将查看命令中指定的所有远程仓库以查找可能的新版本，而不会在找到第一个较新的版本时停止。

版本范围可以在多个地方定义

在 conanfile.py 配方中的 requires、tool_requires、test_requires、python_requires
在 conanfile.txt 文件中的 [requires]、[tool_requires]、[test_requires] 部分
在命令行参数中，如 --requires= 和 --tool_requires。
在配置文件的 [tool_requires] 部分

语义版本控制¶

语义版本控制规范或 semver，规定软件包的版本应始终使用 3 个点分隔的数字，如 MAJOR.MINOR.PATCH，每个数字都有非常具体的含义。

Conan 将 semver 规范扩展到任意数量的数字，并且还允许在其中包含小写字母。这样做是因为在 1.X 期间收集了大量用户的经验和反馈，并且很明显 C++ 中的版本控制方案通常更复杂，用户要求更高的灵活性，允许版本像 1.2.3.a.8 如果有必要。

Conan 版本中非数字的标识符遵循与软件包名称相同的规则，它们只能包含小写字母。这是为了避免 1.2.3-Beta 与 1.2.3-beta 成为不同的版本，这可能会有问题，甚至存在安全风险。

在必要时（例如，决定版本范围内的最新版本）对版本进行排序的方式是，从左到右，单独比较版本中每个点分隔的实体。数字将进行数值比较，因此 2 < 11，并且包含字母的条目将按字母顺序比较（即使它们也包含一些数字）。

与 semver 规范类似，Conan 可以管理 预发布版本 和 构建版本，形式为：VERSION-prerelease+build。Conan 也会根据相同的规则对预发布版本和构建版本进行排序，并且它们中的每一个也可以包含任意数量的项目，如 1.2.3-pre.1.2.1+build.45.a。请注意，semver 标准不对构建应用任何排序，但 Conan 会应用排序，其逻辑与用于排序主版本和预发布版本的逻辑相同。

重要

请注意，预发布版本的排序有时会令人困惑。预发布版本发生的时间早于它所限定的发布版本。因此，1.1-alpha.1 早于 1.1，而不是更新的版本。

范围表达式¶

范围表达式可以有用于下限和上限的比较运算符，用空格分隔。此外，允许单独使用下限和上限，尽管通常不建议在正常的版本控制方案中使用，尤其是只使用下限的情况。 requires = "pkg/[>=1.0 <2.0]" 将包括 1.0、1.2.3 和 1.9 等版本，但不会包括 0.3、2.0 或 2.1 版本。

可以使用波浪号 ~ 运算符来定义“大约”等于的版本范围。requires = "pkg/[~1]" 将包括 1.3 和 1.8.1 等版本，但会排除 0.8 或 2.0 等版本。同样，requires = "pkg/[~2.5]" 将包括 2.5.0 和 2.5.3，但会排除 2.1、2.7、2.8。

插入符号 ^ 运算符与波浪号非常相似，但允许在最后一个定义的数字上发生变化。requires = "pkg/[^1.2]" 将包括 1.2.1、1.3 和 1.51，但会排除 1.0、2、2.0。

也可以使用 OR 运算符应用多个条件，如 requires = "pkg/[>1 <2.0 || ^3.2]"，但实际上不建议使用这种复杂的表达式，而应仅在非常极端的情况下使用。

最后，请注意，默认情况下不会解析预发布版本。将它们包含在范围中的方法是使用 include_prerelease 选项（requires = "pkg/[>1 <2, include_prerelease]"）或通过 core.version_ranges:resolve_prereleases=True 配置显式启用它们。在此示例中，将包括 1.0-pre.1 和 1.5.1-pre1，但会排除 2.0-pre1。

注意

虽然可以在 requires 版本范围中硬编码 include_prerelease，但通常不建议这样做。预发布版本应选择加入，并由用户控制，由用户决定是否要使用预发布版本。此外，请注意，include_prereleases 不接收任何参数，因此无法使用 include_prerelease=False 禁用预发布版本。

有关有效范围表达式的更多信息，请转到 Requires 参考