osgi - API 包的语义版本控制

Question

当从 API 包中版本为 1.0.0 的包开始时，向所述包添加新接口后的新版本应该是什么？白皮书就兼容性做出了以下声明：

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

同时...

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

语义版本确实提到：

如果将任何向后不兼容的更改引入公共 API，则必须增加主要版本X( X.y.z| )。X > 0

如果新接口的添加只是调用几个旧接口，现在链接到一个新操作中，则应该认为它在语义上是向后兼容的。
在这种情况下，小版本增量就足够了。