我熟悉OSGI语义版本控制 - 技术白皮书。但是，我没有看到为OSGI服务提出的任何版本控制概念。
简单的情况：我提供的服务注册为com.services.payments.PaymentService，它阻止方法void makePayment（Integer amount，String accountNo），我打包为1.0版本。然后，我用修改后的界面更新服务。我删除此方法并添加新方法： makePaymentInDifferentWay（Integer amount，String accountNo）并将新服务打包为bundle 2.0版。 在第一个bundle停止后，客户端将在服务调用上连接第二个服务，并且 CRASH ，因为方法签名不是二进制兼容的。 在处理java包时，这种情况是完全解决的，但我没有看到OSGI服务开箱即用的任何版本控制功能。 我错过了什么吗？ （我知道我可以通过设置像'service.version'这样的服务属性来预先设计版本控制方案，并在客户端通过此属性过滤提供的服务，或者只是重命名API包或类名，但为什么没有为该框提供版本控制？也许还有其他一些更为标准的解决方案？也许有一些与服务有关的概念我根本没有掌握？）
答案 0 :(得分：3)
客户端应该在其Import-Package语句（或Require-Bundle）语句中具有版本，例如：
Import-Package: com.services.payments;version="[1.0,2.0)"
该服务将包导出为：
Export-Package: com.services.payments;version="1.0.0"
停止第一个捆绑并安装第二个捆绑后，客户端将无法解析（因为所需的约束，com.services.payments;version="[1.0,2.0)"将不会得到满足。
此外，如果您有两个API包，一个包版本为“1.0.0”，第二个版本为“2.0.0”，客户端导入“1.0.0”API，客户端将不会“看到”服务实现API版本“2.0.0”。
答案 1 :(得分：3)
服务的类型和类型都在包中。因此，服务的版本是包含服务类型的包的版本。当客户端使用与服务提供者相同的服务类型包时，OSGi框架确保仅向客户端公开服务。