API软件包的语义版本控制

Question

在API软件包中以1.0.0版本开始的软件包中，在将新界面添加到该软件包后，新版本应该如何？ whitepaper声明了兼容性：

很明显，二进制兼容性在向后兼容性中起着重要作用。但是，向后兼容性也非常依赖于语义。如果界面的责任发生变化，它仍然可以是二进制兼容的，但不再向后兼容。

同时...

3.micro - 在微观部分的差异不表示有任何向后兼容问题

一个新的界面不会导致任何二进制它的提供者不兼容—它可能简单地省略一个实现。这被认为是包裹语义上的“后向不相容”变化吗？这是否意味着新版本应该是1.1.0？

Answer 1

添加一个接口到一个包至少是一个小的改变（1.2.3 - > 1.3.0），因为你打破了API的提供者（在OSGi是一个包），API的提供者几乎没有向后兼容性，因为它们提供了API。毕竟，API中的任何新义务都需要一些新的代码。

现在假设您在消费者身上放置了一个义务以在API中实现此新接口。这种变化（编译器不可见）明显地打破了所有现有的消费者，并因此成为每个人的突破性变化（例如1.2.3 - > 2.0.0）。

总之：

• 微小变化 - >与API
• 轻微改变现有的提供者和消费者向后兼容 - >现有的API提供者是不兼容的，但消费者是
• 重大变化 - >现有的提供者和消费者不再兼容

Answer 2

的semantic versioning确实提到：

主要版本X（X.y.z | X > 0）如果有不兼容向后变更向公众介绍了API必须递增。

如果除了调用几个旧接口（现在链接成一个新操作），新接口的添加应考虑语义向后兼容。
在这种情况下，次版本增量就足够了。