默认版本管理方法

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

Conan 实现了基于“semver”规范的版本管理，但增加了一些 C 和 C++ 生态系统所要求的功能

  • Conan 版本可以有任意数量的数字，例如 MAJOR.MINOR.PATH.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 自动的配方修订来处理它。一个常见的用例是当 C/C++ 源代码完全没有修改，并且只对 conanfile.py 配方进行更改时。由于源代码相同，我们可能希望保持相同的版本号，并只拥有该版本的新修订。

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

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

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

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

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

注意

最佳实践

  • 不建议使用其他包引用字段（如 user 和 channel）来表示源代码的更改或其他信息（如 git 分支），因为这会“传染”并要求更改消费者的 requires。此外，它们在构建模型中没有实现关于哪些消费者需要重新构建的任何逻辑。

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