我正在考虑在项目中管理版本控制的最佳方法。现在，我们捆绑包中的每个包都会被导出（这将在以后进行改进，所以不要挂在这个失礼上）。我们正在使用maven-bundle-plugin，它从 packageinfo 文件中获取包版本，或者如果没有文件，则从bundle-version（即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内容没有改变，foo也会以1.0.1的形式发布？因为除了在每个导出的包中都有一个 packageinfo 文件之外，开发人员还需要记住碰撞版本（他们会忘记），而捆绑的版本会被maven-release自动碰撞 - 插入。请注意我不是在谈论使用require-bundle。我仍然希望使用import-package来获得它带来的粒度，并且如果需要，可以选择通过packageinfo控制包版本，但我正在尝试简化开发人员的工作流程和记忆，一个想法是仅针对特殊情况而不是推荐的“无处不在”
离开 packageinfo看到它的方式，非常务实，我必须选择使用相同版本发布两个不同软件包的危险（开发人员忘了更改后的数字），这对我来说似乎非常糟糕VS释放两个相同的软件包不同的版本，我不知道它带来了什么危险，因此我的问题
答案 0 :(得分：2)
管理版本的方式可能取决于您编写的软件类型。无论如何，作为包导出的任何内容都是API（无论是内部还是公共）还是您要共享的库。您应该只暴露最小的包以实现良好的解耦。
现在正如您所提到的，有两种流行的版本控制方案：
如果主要是您自己的应用程序依赖于共享包，则Variant 1是合适的。它也很受图书馆的欢迎，因为它很容易添加到现有的库中。它的主要优点是易于实现。只需让maven bundle插件使用其默认值即可。如果使用您共享软件包的软件包与导出软件包的软件包一起发布，则效果最佳。
Variant 2适用于许多松散耦合的其他应用程序使用的API。按包进行仔细的版本管理可确保API中的更改对现有用户的影响最小。价格是你需要更多的考虑和努力来管理版本。因此，OSGi规范就是一个很好的例子。随着时间的推移，它们在引入新功能的同时实现了高度的兼容性。
我可以分享一个案例，其中bundle的版本控制不是最佳的。 servlet API 3.0的第一个预览版仅导出3.0软件包版本。因此，如果这将是正式版本，则使用旧API 2.5的每个捆绑包都必须切换为默认导入范围始终排除下一个主要版本。最后，为所有兼容包导出了旧版本和旧版本。这样可以最大限度地减少对用户的影响。
顺便说一下。如果您使用maven bundle插件，那么即使在通过包进行版本控制的情况下，捆绑包的用户也不必做太多。 Bnd会自动查看每个软件包的版本，并根据此信息而不是软件包版本来确定导入范围。
所以基本上要考虑对用户的影响。特别是当你做一个新的主要版本。测试针对旧版本软件包编译的用户包。