用 OSGi 应用程序开发和工作的最佳实践 （2）

look_w

4. 版本是可控制的为 bundle 和包提供语义版本来启用 API 客户端和提供商之间的松耦合。
原因如下
在 OSGi 中，包和 bundle 是版本可控制的，如果没有指定版本，则默认为 0。包和 bundle 应该是从语义上进行版本库控制的，便于客户端进行自我保护，以防 API 更改而导致中断。
语义版本控制（semantic versioning）定义了一个版本控制模式，使其可以向客户端传递版本兼容信息。语义版本控制 使用主版本号.次版本号.微版本号（major.minor.micro）的编号模式。主版本号、次版本号和微版本号都是自然数（0，1，2，等等）。

• 在主版本中的改变表示一个二进制不兼容 API 改成客户端 API；这就是说，在版本 2 中，API 中进行的客户端编译需要在版本 3 中重编译才能生效。一个二进制不兼容改变的示例是删除一个接口或方法。
• 在次版本中的改变表示 API 已被增强，但是现有客户端不需要被重新编译。这类改变的一个例子就是添加一个接口或一个方法。
• 在微版本中的改变表示已进行了一个改变但是不需要改变 API。这类改变的示例是一个删除 NullPointerException 的 bug 修复。

API 以这种方式控制版本，使客户端可以将 API 版本限制到其可用的范围。当导入一个包或需要一个 bundle 时，客户端可以要求他们想要的版本。例如（1，2）允许客户端使用版本 1 的包或 bundle 进行工作，而不能使用版本 2 的包或 bundle。这是因为客户明白，将来的变更可能是一种使用主版本的二进制兼容变更。
如果语义版本控制用于 bundle 和包，那么在运行时可能立刻会有 API 的多个版本，且和 bundle 同时使用。
到目前为止，最佳实践已经介绍了关于 API 客户端的兼容性。当遵守以下  最佳实践时，API 的实现将在一个独立的 bundle 中，也可从版本控制中获益。对于一个实现者（implementor），主版本或次版本中的改变表示一个二进制不兼容改变，例如，它们可能需要实现一个新接口或方法。（使用语义版本控制的额外优势和注意事项，见 。）
示例
图 3 显示了一个 API 的两个提供商，其中 API 是同一版本。在 OSGi 中，这两个提供商被认为是相同的。客户端（左边）和实现者（右边）都表达了一种依赖，将匹配各自 API 提供商。
图 3. 客户端和实现者可以任意使用两个相同版本的包图 4 显示了不同版本中的两个 API 提供商。也显示了次版本中的一个改变如何分别影响客户端和实现者。既然这样，您可以提供 API 的1.0 版本和 1.1 版本。客户 A 可以使用任何一个 API 提供程序；客户 B 使用新 API 方法，可使用最高版本 1.1。Implementation A 使用 bundle API A 提供的 API，而 Implementation B 只使用 bundle API B 提供的 API 。
服务注册表将对请求者可见的服务限制在执行与包绑定的 API 版本的那些请求者范围内，知道这一点很重要。
图 4. 一个次要 API 版本改变如何不同程度地影响客户端和实现图 5 从客户和实现者角度显示了一个不兼容的 API 改变。既然这样，Implementation A 和 Client A 被绑定到 API A，Implementation B 和 Client B 绑定到 API B。
图 5.  一个主要 API 版本改变如何同样影响客户端和实现