API 包的语义版本控制 [英] semantic versioning of API bundle

问题描述

从 API 包中版本为 1.0.0 的包开始时，在向所述包添加新接口后新版本应该是什么?白皮书 做出了关于兼容性的声明:

When starting with a package versioned at 1.0.0 in an API bundle, what should the new version be after adding a new interface to said package? The whitepaper makes this statement regarding compatibility:

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

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 — 微部分的差异并不表示存在任何向后兼容性问题

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

新接口不会导致其提供者的任何二进制不兼容——很可能简单地省略实现.这是否被认为是包语义的向后不兼容"更改?这是否意味着新版本应该是 1.1.0?

A new interface does not result in any sort of binary incompatibility for its providers—it is quite possible to simply omit an implementation. Is this considered a "backward-incompatible" change in the semantics of the package? Does this imply the new version should be 1.1.0?

推荐答案

向包添加接口至少是一个小改动 (1.2.3 -> 1.3.0)，因为您破坏了 API 的提供者(在OSGi 是一个包)，API 的提供者实际上没有向后兼容性，因为他们提供 API.毕竟，API 中的任何新义务都需要一些新代码.

Adding an interface to a package is at least a minor change (1.2.3 -> 1.3.0) since you break the provider of the API (which in OSGi is a package), providers of an API have virtually no backward compatibility since they, well, provide the API. After all, any new obligation in the API requires some new code.

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

Now assume you put an obligation on the consumer to implement this new interface in the API. This change (not visible to the compiler) obviously breaks all existing consumers and will therefore be a breaking change for everybody (e.g. 1.2.3 -> 2.0.0).

总结:

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

这篇关于API 包的语义版本控制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！