这可能是一个奇怪的问题，所以请耐心等待。
我有一个Tycho / Eclipse插件，它只包含一个包含第三方库的lib文件夹。该库的版本为1.17.0，因此为了使该过程更加透明，插件也是如此。
它导出了lib的所有包，一切都很好。至少它是，因为现在我意识到，如果我使用版本导出包，那将会好得多。插件1.17.0已经发布（我知道，Tycho通常不会发布，只是假设我不想重新使用已经稳定一年的版本。）
作为OSGi bundle，我不允许使用版本1.17.0.1或1.17.0B或其他东西，但我不能只使用版本1.17.1，因为它会暗示第三方库也是1.17.1，但事实并非如此。目前无法更新第三方库，因为时间至关重要。
我刚刚尝试了1.17.01并且没有人抱怨，但我不确定Maven和OSGI如何根据1.17.0和1.17.1对此版本进行排序。 The Maven manual does not really talk about zeros，但我想它会强制进行字符串比较，在完全搞砸的版本排序中产生。
那么......我可以安全使用哪个版本？
答案 0 :(得分：1)
你可以使用＆＃34; 1.17.0.p1＆＃34;表示＆＃34;补丁1＆＃34; - 使用OSGi作为＆＃34可以正常;限定符可以是任何字符串，按字典顺序排序＆＃34; （引自您的OSGi链接）。 ＆＃34; P1＆＃34;类似于＆＃34; beta1＆＃34;等限定符。或＆＃34; RC1＆＃34;或者......
major.minor.micro.qualifier
这也适用于Maven。而且，我们可以假设您不会提供一系列超过十个补丁（至少我假设）。
就个人而言，我会避免引导零，因为这看起来很奇怪。一系列HotFix或Patch版本应该会导致偶尔增加更高版本号。
答案 1 :(得分：0)
我不确定Tycho，但OSGI框架将版本的前三部分视为数字，并使用int将其转换为Integer.parseInt（请参阅org.osgi.framework.Version）。
因此'01'将被视为与'1'完全相同。
答案 2 :(得分：0)
对于新的bundle版本，你需要确保在OSGi语义方面更大 - Maven语义在这里并不重要。因此，您需要增加前三个片段之一的数值（例如1.17.1）或添加第四个片段。第四个段，即所谓的限定符，是一个字符串，OSGi认为具有限定符的版本大于没有限定符的相同版本。所以你可以例如使用1.17.0.a。
对于要使用新捆绑版本引入的更改的一个警告，即向导出的包添加版本。使用版本导出包是绝对有意义的，但是为包选择正确的版本至关重要。
经验表明使用库版本作为包版本是一个坏主意：当我们为javax.mail 1.4.1构建OSGi包装器时，我们还使用了1.4.1版本导出包。但是当Sun在版本1.4.2中将javax.mail发布为OSGi包时，他们认为这些包符合1.4 API协议，因此将它们导出为1.4版。因此，我们的旧版本的库假装其导出的包更好，因此OSGi解析比较新的库版本更喜欢它。
更糟糕的是，我们在此期间还有许多其他捆绑包需要最低版本为1.4.1的javax.mail包，因此甚至不能强制使用较新的库版本。最后，我们花了一年多的时间来清理我们在OSGi包装器中选择错误的软件包版本所带来的麻烦。
结论：在将您不拥有的库转换为OSGi包时，只有使用非常小的包版本号。当使用零版本号作为主要版本时，例如0.1.17，你应该保证你自己发明的版本比以后的所有“官方”版本要小。