OSGi 包中的版本更改

Question

我正在考虑在我们的项目中管理版本控制的最佳方式。目前，我们的包中的每个包都被导出（这将在以后改进，所以不要挂断这个失礼）。我们正在使用 maven-bundle-plugin，它可以从 packageinfo 文件中获取 package 版本，或者如果没有文件，则从 bundle-version（即 pom版本）。

所以我的问题是，似乎每个包都有一个 packageinfo 很多（再次，我知道减少导出的包可以解决这个问题）所以我想知道为什么最好有一个每个包的版本而不是全局版本（捆绑版本）？

所以说捆绑 A 已发布

 A (1.0.0)
 |...foo (1.0.0)
 |...bar (1.0.0)

现在如果 package bar 发生变化，发布 bundle A 的理想方式是

 A (1.0.1)
 |...foo (1.0.0)
 |...bar(1.0.1)

拥有一个版本以使 foo 发布为 1.0.1，即使它的内容没有改变，会不会很糟糕（如果是，为什么？）？因为除了在每个导出的包中都有一个 packageinfo 文件外，开发人员还需要记住调整版本（他们会忘记），而包的版本是由 maven-release- 自动调整的插入。请注意，我不是在谈论使用 require-bundle。我仍然想使用 import-package 来获得它带来的粒度，并在需要时可以选择通过 packageinfo 控制包版本，但我正在尝试简化开发人员的工作流程和记忆，一个想法是仅在特殊情况下保留 packageinfo 而不是推荐的“无处不在”

看到它的方式，非常务实，我必须在发布具有相同版本的两个不同软件包的危险之间做出选择（开发人员在更改后忘记增加数字），这对我来说似乎非常糟糕 VS 发布两个相同的软件包使用不同的版本，我不知道它会带来什么危险，因此我的问题

Answer 1

您管理版本的方式可能取决于您编写的软件类型。在任何情况下，您作为包导出的任何内容都是 API（无论是内部的还是公共的）或您想要共享的库。您应该只公开最少的包以实现良好的解耦。

现在正如您所提到的，有两种流行的版本控制方案：

1. 对整个捆绑包进行版本控制。这意味着每个包导出都有包的版本
2. 分别对每个包进行版本控制

如果您自己的应用程序主要依赖于共享包，则变体 1 是合适的。它在库中也很受欢迎，因为它很容易添加到现有库中。主要优点是容易实现。只需让 Maven 捆绑插件使用其默认值。如果使用您共享包的包与导出包的包一起发布，则效果最佳。

变体 2 适用于许多松散耦合的其他应用程序使用的 API。按包进行仔细的版本管理可确保 API 的更改对现有用户的影响最小。代价是您需要更多的考虑和努力才能很好地管理版本。因此，OSGi 规范就是一个很好的例子。随着时间的推移，它们在引入新功能的同时实现了出色的兼容性。

我可以分享一个案例，即按包进行版本控制不是最佳的。 servlet API 3.0 的第一个预览版只导出了 3.0 包版本。因此，如果这将是正式版本，那么每个使用旧 API 2.5 的包都必须切换，因为默认导入范围总是排除下一个主要版本。最后，为所有兼容包导出了新旧版本。这样可以最大限度地减少对用户的影响。

顺便说一句。如果您使用 maven bundle 插件，那么即使在按包进行版本控制的情况下，bundle 的用户也不必做太多事情。 Bnd 会自动查看每个包的版本，并将导入范围基于此信息而不是包版本。

所以基本上要考虑对用户的影响。特别是当你做一个新的主要版本时。测试针对旧版本包编译的用户包。