Eug*_*sky 2 versioning osgi api-design backwards-compatibility semantics
当在API捆绑包中以1.0.0版本的版本开始时,在向所述包添加新接口之后新版本应该是什么？该白皮书使得关于兼容性这一说法:
显然,二进制兼容性在向后兼容性中起着重要作用.但是,向后兼容性也非常依赖于语义.如果接口的责任发生变化,它仍然可以是二进制兼容的,但不再向后兼容.
同时...
3.micro - 微观部分的差异并不表示任何向后兼容性问题
新接口不会导致其提供程序的任何二进制不兼容性 - 很可能只是省略一个实现.这被认为是包的语义中的"向后不兼容"的变化吗？这是否意味着新版本应该是1.1.0？
添加一个接口到一个包至少是一个小的改变(1.2.3 - > 1.3.0),因为你打破了API的提供者(在OSGi中是一个包),API的提供者实际上没有向后兼容性,因为他们好吧,提供API.毕竟,API中的任何新义务都需要一些新代码.
现在,假设你把一个义务,对消费者实行API在这个新的接口.这种变化(对编译器不可见)显然会破坏所有现有的消费者,因此对每个人来说都是一个突破性的变化(例如1.2.3 - > 2.0.0).
总结: