本文档翻译自：https://docs.conan.io/en/latest/creating_packages/define_abi_compatibility.html#dependency-issues

    让我们定义一个简单的场景，其中有两个包: my_other_lib/2.0和my_lib/1.0，这取决于my_other_lib/2.0。 假设他们的配方和二进制文件已经创建并上传到Conan远程服务器。

    现在，发布了my_other_lib/2.1 的新版本，其中包含改进的配方和新的二进制文件。my_lib/1.0 已修改，需要升级到my_other_lib/2.1。

    :::info Note
    如果消费项目my_lib / 1.0定义了对my_other_lib / 2.1的依赖关系，而该依赖项优先于my_lib / 1.0中的现有项目，则此方案将相同。 :::

    问题是: 是否有必要构建新的my_lib/1.0 二进制包？还是现有的包仍然有效？
    答案是: 视情况而定。

    让我们假设这两个包都被编译为静态库，并且my_other_lib通过公共头向my_lib/1.0 公开的API根本没有改变。在这种情况下，不需要为my_lib/1.0 构建新的二进制文件，因为最终的使用者将同时链接到 my_lib/1.0 和 my_other_lib/2.1。

    另一方面，公共头中my_other_lib公开的API可能发生了变化，但是不会因为任何原因影响my_lib/1.0 二进制文件 (例如由my_lib不使用的新功能组成的更改)。如果MyOtherLib只是标题，同样的推理也适用。
    但是，如果名为myadd.h的my_other_lib的头文件从 2.0 更改为 2.1，该怎么办:

    2.0 版中的myadd.h头文件

    1. int addition (int a, int b) { return a - b; }

    2.1 版中的myadd.h头文件

    1.  int addition (int a, int b) { return a + b; }

    并且从编译的函数中调用addition() 函数。My_lib/1.0 的cpp文件？
    然后，需要为新的依赖项版本构建my_lib/1.0 的新二进制文件。
    否则，它将保持旧的、有缺陷的addition() 版本。即使 my_lib/1.0 的代码行在配方中也没有任何更改，生成的二进制重建my_lib也需要my_other_lib/2.1，并且包要不同。