默认版本控制方法

在更改包的源代码并创建该包时，一个好的做法是增加包的版本，以表示这些更改的范围和影响。“semver”标准规范定义了一种 MAJOR.MINOR.PATCH 版本控制方法，其中更改每个数字都有特定的含义。

Conan 实现了基于“semver”规范的版本控制，但具有一些 C 和 C++ 生态系统要求的扩展功能

  • Conan 的版本可以有任意数量的数字，例如 MAJOR.MINOR.PATCH.MICRO.SUBMICRO...

  • Conan 的版本也可以包含字母，而不仅仅是数字，并且它们也按字母顺序排序，因此 1.a.2 比 1.b.1 更旧，例如。

  • 版本范围可以为任意数量的数字定义，例如 dependency/[>=1.0.0.0 <1.0.0.10]

请阅读 版本控制简介 在教程中。

但与其它语言的构建模型相比，C 和 C++ 构建模型的一个非常不同的方面是依赖项如何影响需要它们的消费者的二进制文件。这在 Conan 二进制模型 参考中描述。

基本上，当某个包更改其版本时，这可能会对该包的“消费者”产生不同的影响，要求这些“消费者”从源代码重新构建或不集成新的依赖项更改。这还取决于包的类型，因为链接共享库或静态库时的逻辑会发生变化。Conan 二进制模型使用 dependency traits、package_type 和 package_id 模式，能够表示这种逻辑并有效地计算需要从源代码重新构建的内容。

Conan 的默认行为可以提示在对包的源代码进行不同更改时，建议进行哪些版本更改

  • 不修改版本通常意味着我们希望 Conan 自动 **recipe 修订版** 来处理它。一个常见用例是当 C/C++ 源代码根本没有修改时，并且只对 conanfile.py recipe 进行了更改。由于源代码相同，我们可能希望保留相同的版本号，而只是拥有该版本的新的修订版。

  • **补丁 (Patch)**：增加包的 **补丁** 版本意味着只进行了内部更改，实际上意味着更改了包的非公共头文件。这个“补丁”版本可以避免重建该包的消费者，例如，如果当前包获得一个新的“补丁”版本是一个静态库，那么所有依赖于此静态库的其他包都不需要从源代码重新构建，因为依赖于相同的公共接口头文件保证了相同的二进制文件。

  • **次要 (Minor)**：如果对包的公共头文件进行了更改，并且以 API 源代码兼容的方式进行了更改，那么建议增加包的 **次要** 版本。这意味着依赖于它的其他包将能够在没有问题的情况下编译，但由于公共头文件发生了修改（可能包含 C++ 模板或其他可能内联到消费者包中的内容），因此这些消费者包需要从源代码重新构建以合并这些更改。

  • **主要 (Major)**：如果对包的公共头文件进行了 API 破坏性更改，那么建议增加 **主要** 版本。由于最常见的推荐版本范围是类似于 dependency/[>1.0 <2] 的内容，其中排除下一个主要版本，这意味着发布这些新版本不会破坏现有的消费者，因为它们不会被这些消费者使用，因为它们的版本范围将排除它们。为了能够使用新的主要版本，需要修改消费者的 recipe 和源代码（以修复 API 破坏性更改）。

请注意，虽然这接近于标准“semver”版本和版本范围的定义，但 C/C++ 编译模型需要引入一个新的副作用，即“需要重建消费者”，遵循上述逻辑中的 embed 和 non_embed 情况。

这只是默认的推荐版本控制方法，但 Conan 允许更改这些默认值，因为它实现了“semver”标准的扩展，允许任意数量的数字、字母等，并且它还允许更改 package_id 模式以定义依赖项的不同版本如何影响消费者的二进制文件。请参阅 如何自定义依赖项 package_id 模式。

注意

最佳实践

  • 不建议使用其他包引用字段，例如 user 和 channel 来表示源代码中的更改，或其他信息，例如 git 分支，因为这会变得“病毒式”传播，需要更改消费者的 requires。此外，它们没有在构建模型中实现任何逻辑，以确定哪些消费者需要重新构建。

  • 推荐的方法是使用版本控制和多个服务器存储库来托管不同的包，这样它们就不会干扰其他构建，请阅读 持续集成教程 以获取更多详细信息。