默认版本控制方法¶

当对包的源代码进行更改并创建此类包时，一个好的做法是增加包的版本，以表示这些更改的范围和影响。“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 二进制模型参考中进行了描述。

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

默认的 Conan 行为可以给出一些关于在对包源代码进行不同更改时建议使用哪些版本更改的提示

不修改版本通常意味着我们希望 Conan 自动recipe 修订来处理它。一个常见的用例是，当 C/C++ 源代码完全未修改，而仅对 conanfile.py recipe 进行更改时。由于源代码相同，我们可能希望保持相同的版本号，并且仅具有该版本的新修订。
Patch：增加包的 patch 版本意味着仅进行了内部更改，实际上这意味着更改包的非公共标头的文件。此“patch”版本可以避免重建此包的消费者，例如，如果当前获取新“patch”版本的包是静态库，则所有实现依赖于此静态库的静态库的其他包都不需要从源代码重建，因为依赖于相同的公共接口标头保证了相同的二进制文件。
Minor：如果对包公共标头进行了更改，并且以 API 源兼容的方式进行，则建议增加包的 minor 版本。这意味着其他依赖于它的包将能够编译而不会出现问题，但是由于公共标头中存在修改（其中可能包含 C++ 模板或可能在消费者包中内联的其他内容），因此需要从源代码重建这些消费者包以合并这些更改。
Major：如果对包公共标头进行了 API 破坏性更改，则建议增加 major 版本。由于最常见的建议版本范围类似于 dependency/[>1.0 <2]，其中排除了下一个 major 版本，这意味着发布这些新版本不会破坏现有的消费者，因为这些消费者根本不会使用它们，因为它们的版本范围将排除它们。有必要修改消费者的 recipe 和源代码（以修复 API 破坏性更改）才能使用新的 major 版本。

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

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

注意

最佳实践

不建议使用其他包引用字段，例如 user 和 channel 来表示源代码中的更改或其他信息（如 git 分支），因为这会变得“病毒式传播”，需要更改消费者的 requires。此外，它们不会在构建模型中实现任何关于哪些消费者需要重建的逻辑。
建议的方法是使用版本控制和多个服务器存储库来托管不同的包，因此它们不会干扰其他构建，请阅读持续集成教程了解更多详细信息。