版本¶

本节解释了如何创建给定包的不同版本，首先从手动更改 conanfile.py 食谱中的版本属性开始，然后引入 set_version() 方法作为自动化包版本定义的机制。

注意

本节使用非常简单、空的食谱，不构建任何代码，因此没有 build()、package() 等，以最简单的食谱说明版本控制，并允许示例轻松运行，并且非常快速和简单。在现实生活中，食谱将是完整的食谱，如教程的前几节所示，构建实际的库和包。

让我们从一个非常简单的食谱开始

conanfile.py¶

from conan import ConanFile

class pkgRecipe(ConanFile):
    name = "pkg"
    version = "1.0"

    # The recipe would export files and package them, but not really
    # necessary for the purpose of this part of the tutorial
    # exports_sources = "include/*"
    # def package(self):
    #    ...

我们可以创建 pkg/1.0 包

$ conan create .
...
pkg/1.0 .
...

$ conan list "pkg/*"
Local Cache
  pkg
    pkg/1.0

如果我们现在对该库的源文件进行了一些更改，这将是一个新版本，我们可以将 conanfile.py 版本更改为 version = "1.1" 并创建新的 pkg/1.1 版本

# Make sure you modified conanfile.py to version=1.1
$ conan create .
...
pkg/1.1 .
...

$ conan list "pkg/*"
Local Cache
  pkg
    pkg/1.0
    pkg/1.1

正如我们所看到的，现在我们在缓存中看到了 pkg/1.0 和 pkg/1.1。Conan 缓存可以为同一个 pkg 包存储任意数量的不同版本和配置。

自动化版本¶

除了手动更改 conanfile.py 中的版本，还可以通过 2 种不同的方法实现自动化。

首先，可以直接在命令行中提供 version。在上面的示例中，我们可以从食谱中删除 version 属性并执行

# Make sure you removed the version attribute in conanfile.py
$ conan create . --version=1.2
...
pkg/1.2 .
...

$ conan list "pkg/*"
Local Cache
  pkg
    pkg/1.0
    pkg/1.1
    pkg/1.2

另一种可能性是使用 set_version() 方法动态定义版本，例如，如果版本已存在于源代码或文本文件中，或者应该从 git 版本中推断出来。

假设我们在仓库中有一个 version.txt 文件，其中只包含版本字符串 1.3。那么，可以这样操作

conanfile.py¶

from conan import ConanFile
from conan.tools.files import  load


class pkgRecipe(ConanFile):
    name = "pkg"

    def set_version(self):
        self.version = load(self, "version.txt")

# No need to specify the version in CLI arg or in recipe attribute
$ conan create .
...
pkg/1.3 .
...

$ conan list "pkg/*"
Local Cache
  pkg
    pkg/1.0
    pkg/1.1
    pkg/1.2
    pkg/1.3

还可以结合命令行版本定义，如果未提供命令行参数，则回退到从文件中读取，语法如下

conanfile.py¶

def set_version(self):
    # if self.version is already defined from CLI --version arg, it will
    # not load version.txt
    self.version = self.version or load(self, "version.txt")

# This will create the "1.4" version even if the version.txt file contains "1.3"
$ conan create . --version=1.4
...
pkg/1.4 .
...

$ conan list "pkg/*"
Local Cache
  pkg
    pkg/1.0
    pkg/1.1
    pkg/1.2
    pkg/1.3
    pkg/1.4

同样，也可以从 Git 标签中获取版本

conanfile.py¶

from conan import ConanFile
from conan.tools.scm import Git

class pkgRecipe(ConanFile):
    name = "pkg"

    def set_version(self):
        git = Git(self)
        tag = git.run("describe --tags")
        self.version = tag

# assuming this is a git repo, and it was tagged to 1.5
$ git init .
$ git add .
$ git commit -m "initial commit"
$ git tag 1.5
$ conan create .
    ...
    pkg/1.5 .
    ...

$ conan list "pkg/*"
Local Cache
  pkg
    pkg/1.0
    pkg/1.1
    pkg/1.2
    pkg/1.3
    pkg/1.4
    pkg/1.5

注意

最佳实践

我们可以尝试使用分支名称或提交作为版本号。然而，这可能会有一些缺点，例如，当需要此包时，它需要每个要求此包的其他包食谱中都有一个明确的 requires = "pkg/commit"，并且可能难以一致地更新消费者，也难以知道正在使用更新的还是更旧的依赖项。

要求新版本¶

当创建新包版本时，如果要求此包的其他包食谱包含明确的 requires，例如固定确切版本

app/conanfile.py¶

from conan import ConanFile

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

那么，安装或创建 app 食谱将继续要求并使用 pkg/1.0 版本，而不是更新的版本。要开始使用新的 pkg 版本，需要明确更新 requires，例如

app/conanfile.py¶

from conan import ConanFile

class AppRecipe(ConanFile):
    name = "app"
    version = "1.0"
    requires = "pkg/1.5"

这个过程虽然实现了非常好的可重现性和可追溯性，但如果我们管理着一个庞大的依赖关系图，并且希望更快地、更少手动干预地使用最新的依赖关系版本，这可能会有点繁琐。为了自动化此过程，可以使用下一节中解释的*版本范围*。