OSGi包中的版本更改

我正在考虑在我们的项目中管理版本控制的最佳方法。目前，我们捆绑包中的每个包都是导出的（这将在以后得到改进，所以不要因为这个失礼而挂断电话）。我们使用的是maven bundle插件，它要么从packageinfo文件中获取包版本，要么如果没有文件，从bundle版本（即pom版本）获取

所以我的问题是，似乎每个包都有一个packageinfo是一件非常重要的事情（同样，我知道减少导出包可以解决这个问题），所以我想知道为什么每个包都有一个版本比全局版本（捆绑版本）更好

所以说包A被释放了

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

现在，如果包栏发生变化，那么发布包A的理想方法是

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

如果只有一个版本，即使内容没有改变，foo还是以1.0.1的形式发布，这会很糟糕吗（如果是，为什么？）？因为除了在每个导出的包中都有一个packageinfo文件外，开发人员还需要记住升级版本（他们会忘记），而包的版本是由maven发布插件自动升级的。请注意，我不是说使用requirebundle。我仍然希望使用import package来获得它所带来的粒度，并且如果需要的话，可以选择通过packageinfo来控制包的版本，但是我试图简化开发人员的工作流程和记忆，其中一个想法是让packageinfo只用于特殊情况，而不是推荐的“无处不在”

---

在a看来，非常务实，我不得不在发布两个相同版本的不同软件包（开发者在更改后忘了增加数量）的危险与发布两个相同版本的软件包之间做出选择，这对我来说非常糟糕，我不知道会带来什么危险，因此，我的问题是，管理版本的方式可能取决于您编写的软件类型。在任何情况下，导出为包的内容都是API（内部或公共）或要共享的库。您应该只公开最小的包来实现良好的解耦

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

对整个包进行版本控制。这意味着每个包导出都有包的版本

分别对每个包进行版本控制

如果您自己的应用程序主要依赖于共享包，那么变体1是合适的。它也很受图书馆欢迎，因为它很容易添加到现有的图书馆中。其主要优点是易于实现。只需让maven bundle插件使用其默认值即可。如果使用共享包的包与导出包的包一起发布，效果最好

变体2适用于许多松散耦合的其他应用程序所使用的API。通过软件包进行仔细的版本管理，确保API中的更改对现有用户的影响最小。代价是你需要更多的考虑和努力来管理好这些版本。OSGi规范就是一个很好的例子。随着时间的推移，它们在引入新功能的同时实现了高度的兼容性

我可以分享一个案例，按bundle进行版本控制不是最优的。ServletAPI3.0的第一次预览仅导出了3.0包版本。因此，如果这是正式版本，那么使用旧API 2.5的每个捆绑包都必须切换，因为默认导入范围始终排除下一个主要版本。最后，导出了所有兼容软件包的新版本和旧版本。这样可以最大限度地减少对用户的影响

顺便说一句，如果您使用maven bundle插件，那么bundle的用户就不需要做很多事情，即使是按包进行版本控制。Bnd会自动查看每个包的版本，并根据此信息（而不是捆绑包版本）确定导入范围

---

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

请澄清。为什么用相同的版本再次发布包会有危险？如果软件包自上一次发布以来没有实际更改，那么它应该是相同的版本。我的意思是，危险在于发布一个使用相同版本更改的软件包。在这种情况下，开发人员更改了代码，但没有在packageinfo中增加数字。我正在比较这与总是冲击软件包版本的影响，即使软件包没有改变。希望这是清楚的。我不同意。正如你所说，方案1从来没有用过。如果您要这样做，那么根本不用麻烦对包进行版本控制，因为您分配的版本没有任何意义。不幸的是，我现在没有时间写一个完整的答案来解释这一点，但我会这样做。我提到的方案被大多数项目使用。因此，虽然它并不完美，但它的目的是让这些项目在OSGi中可用。如果您希望他们执行正确的基于包的版本控制，那么他们可能根本就没有OSGi元数据。@NeilBartlett我对您解释为什么Scheme 1从来没有用过的完整答案感兴趣。请在此处提供链接时发布。我目前也在根据软件需求选择这两个方案。