API捆绑程序的语义版本控制 [英] semantic versioning of API bundle

查看:103
本文介绍了API捆绑程序的语义版本控制的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

从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

新接口对其提供程序不会造成任何类型的 binary 不兼容-完全可以省略实现.这是否被视为软件包语义上的向后不兼容"更改?这是否意味着新版本应为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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆