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

核心提示： 4. 版本是可控制的为 bundle 和包提供语义版本来启用 API 客户端和提供商之间的松耦合，原因如下在 OSGi 中，用 OSGi 应用程序开发和工作的最佳实践(5)，包和 bundle 是版本可控制的，如果没有指定版本，它们可能需要实现一个新接口或方法，（使用语义版本控制的额外优势和注意

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 最佳实践时，API 的实现将在一个独立的 bundle 中，也可从版本控制中获益。对于一个实现者（implementor），主版本或次版本中的改变表示一个二进制不兼容改变，例如，它们可能需要实现一个新接口或方法。（使用语义版本控制的额外优势和注意事项，见 OSGi Alliance Semantic Versioning Technical Whitepaper。）