osgi - API 包的语义版本控制

Question

从 API 包中版本为 1.0.0 的包开始时，在为该包添加新接口(interface)后，新版本应该是什么？ whitepaper就兼容性发表以下声明:

It should be obvious that binary compatibility plays an important role in backward compatibility. However, backward compatibility is also very dependent on the semantics. If the responsibility of an interface changes it could still be binary compatible but no longer be backward compatible.

同时……

3.micro — A difference in the micro part does not signal any backward compatibility issue

一个新的接口(interface)不会导致它的提供者出现任何类型的二进制不兼容——很可能简单地省略一个实现。这是否被认为是包语义的“向后不兼容”更改？这是否意味着新版本应该是 1.1.0？

Answer 1

将接口(interface)添加到包中至少是一个微小的变化(1.2.3 -> 1.3.0)，因为您破坏了 API 的提供者(在 OSGi 中是一个包)，API 的提供者几乎没有后退兼容性，因为它们提供 API。毕竟，API 中的任何新义务都需要一些新代码。

现在假设您为消费者设置了一个义务，以在 API 中实现这个新接口(interface)。这种变化(编译器不可见)显然破坏了所有现有的消费者，因此对每个人来说都是一个破坏性的变化(例如 1.2.3 -> 2.0.0)。

总结:

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