只要库的外部 API 向后兼容，向库添加新依赖项是否会影响二进制兼容性？
我的CBOR library 包含用于任意精度算术的类（在 PeterO 命名空间中）。 （它在 C# 和 Java 中；Java 版本位于单独的存储库中，但同样的问题适用于两个版本。）
我已将这些类移动到新的命名空间（在 PeterO.Numbers 中），并重命名它们（保留原始类以实现向后兼容性），因为它们现在所在的命名空间仅包含实用程序类。我计划将新类移动到一个单独的库中，并使 CBOR 库将该库作为依赖项调用，因为任意精度的类显然在 CBOR 之外很有用。 （我计划最终弃用旧类。）
但我担心以这种方式创建单独的库是否会导致二进制兼容性问题，这样我就不能只更新次要版本，还要更新主要版本。在撰写本文时，CBOR 库的版本为 2.3.1。我可以这样做并将版本更改为 2.4 还是仅 3.0？
【问题讨论】：
标签： java c# binary-compatibility
只要您从一个界面开始，并且所有图书馆的客户都知道该界面，您就可以了。只要您的库具有其客户能够理解的接口并且实现了该接口，您的代码位于库中的哪个位置或位于库外部的库中的哪个位置都没有关系。
这是一个古老的问题，15 年前由 COM（组件对象模型）解决了。将您的接口与实现分开，这样您就很出色了。
【讨论】：
我会回答 Java 版本。 This section of the Java Language Specification 详细描述了在保持二进制兼容性的同时可以对应用程序进行的更改。
据我了解，您的更改（尽管它们可能会影响大部分源代码）是简单的重构，将一些实用程序类公开给另一个模块，并重新定向旧类以调用这个新模块。这在Evolution of Packages 部分中有描述：
可以将新的顶级类或接口类型添加到包中，而不会破坏与预先存在的二进制文件的兼容性，前提是新类型不会重用先前赋予无关类型的名称。
因此，这不会破坏与使用您的库的现有类的二进制兼容性。任何用于调用CBORUtil.doArithmetic() 的现有类CBORClient 将继续工作而无需重新编译它，因为该方法仍然存在，只是它的主体已更改为调用另一个模块来进行计算。
【讨论】：
最好避免在下一个主要版本之前添加新的依赖项，在此之前，在内部添加更改并创建具有相同类的新任意精度库并在没有依赖项的情况下同步它们。
所以对于 2.4 版，在新命名空间中添加更改并从旧类调用它们，并为任意精度类创建另一个类库并将它们同步到 CBOR 库的下一个主要版本
【讨论】：