默认版本控制方法¶

在对包的源代码进行更改并创建此类包时，一个好的做法是增加包的版本，以反映这些更改的范围和影响。“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 和 C++ 的构建模型与其它语言的一个非常不同的方面是依赖项如何影响需要它们的消费者的二进制文件。这在Conan 二进制模型参考中进行了描述。

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

默认的 Conan 行为可以为对包源代码进行不同更改时建议的版本更改提供一些线索

通常不修改版本意味着我们希望 Conan 自动的 **recipe revisions** 来处理。一个常见的用例是当 C/C++ 源代码根本未修改，并且只修改了 conanfile.py recipe。由于源代码相同，我们可能希望保持相同的版本号，并只获得该版本的新 revision。
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。此外，它们不会在构建模型中实现关于哪些消费者需要重新构建的逻辑。
推荐的方法是使用版本控制和多个服务器仓库来托管不同的包，这样它们就不会干扰其他构建，请阅读持续集成教程以获取更多详细信息。