OSGi放弃了Snapshot提议
OSGi联盟最近发布了OSGi R5的预览文档。在这个即将发布的规范里，最令人期待的功能之一是鉴于SNAPSHOT对现有工具的影响，规范去掉了SNAPSHOT风格的版本：
与现有工具、管理和配置系统之间的交互很让人担心。这些系统处理不了带有预发布（也就是SNAPSHOT）版本字符串的Bundle。它们要做很多修改才能正确处理预发布版本的语法。
问题的根源在于，Maven（以及与Maven兼容的解析程序和构建系统，比如Ivy和Gradle）和OSGi对空标识符的处理方式恰恰相反。在Maven里，1.2.3.2012 <= 1.2.3，但在OSGi里，1.2.3.2012 >= 1.2.3。
假如构建的组件既要在非OSGi环境里工作（比如使用Maven）、又要在OSGi容器里运行，这就会带来问题。Maven的惯例是处理很多个2.1-SNAPSHOT，然后才把版本替换成2.1。Artifactory或Nexus等仓库管理器通常则是在发布的时候把快照重写到过时的文件里，以保证可追溯性。
Eclipse PDE Build和Maven Tycho在构建组件时，则会明确指定组件的名称，通常也会把不断变化的日期/时间戳作为构建的一部分。由于要构建的所有组件都有新的名称，所以版本可能会增量安装到OSGi运行时环境里，新的版本会覆盖另一个。
不幸的是，这意味着“最终”版的组件也包含构建标识符，这些标识符在某些情况下比制品的名称还要长（比如org.junit_4.8.2.v4_8_2_v20110321-1705）。标识符的格式也不一致（例如org.eclipse.jdt.ui_3.7.1.r371_v20110824-0800.jar）。
SpringSource等一些生产者创建的版本形式则是1.2.3.M1、1.2.3.M2、1.2.3.RELEASE，它们既能用于OSGi，也能用于Maven。
OSGi之前想支持-SNAPSHOT风格的版本，来解决这个问题。有人提议改进Bundle-Version的语法，允许1.2.3-456比1.2.3小，Equinox已经这么实现了。这能让Bundle开发者在开发时使用-SNAPSHOT风格的变量（Tycho和PDE等工具都把-SNAPSHOT当成是“神奇的替换值”，而没用使用“.qualifier”），然后再发布1.2.3作为此序列的唯一构建版本，接着又会突然变成1.2.4-SNAPSHOT。
很不幸，这种解决方式是臆测出来的，并没有实证依据：
除此之外，我们开始关注预发布版本的复杂度。在CPEG里展开讨论、与同行进行沟通的时候，大家都弄不明白版本的顺序，也搞不清楚有些版本是否包含在特定的范围内。如果我们这些“专家”都不能时刻保持清醒，那我们也不用指望别人能很容易地理解。
这种混乱与怎样界定构建范围是有关系的。我们看一下现有情况，以[1.0,2.0)为例，这个区间的1.0表示允许1.0-*的快照版本，而2.0则表示不能出现2.0-*的快照版本。归结起来就是，闭区间包含快照、开区间不包含快照，这似乎很难记。
这个决定实际上不利于推广用OSGi生成的内容。大概在一年前，大家对如何在Maven名字空间里表示Eclipse构建的制品展开了讨论，结论是把组件映射成org.eclipse.*的风格，并带上完整的制品名称。但Snapshot提议最终去掉了所有的标识符，以方便大家使用，至少Maven这么做了。
对于需要处处使用标识符的地方，这就有问题了。在提交构建好的组件时，开发人员要是忘了更新版本号，而只用自动生成的数字，那就会导致 Eclipse的仓库里会有很多主版本、小版本、补丁号都一样，只有构建标识符不同的制品。本地的Eclipse 3.7要升级到3.7.2，下面的一组插件就有着相同的主版本、小版本、补丁号：
- org.eclipse.cdt.codan.checkers.ui_1.0.0.201109151620.jar
- org.eclipse.cdt.codan.checkers.ui_1.0.0.201202111925.jar
- org.eclipse.core.filebuffers_3.5.200.v20110505-0800.jar
- org.eclipse.core.filebuffers_3.5.200.v20110928-1504.jar
- org.eclipse.core.variables_3.2.500.v20110511.jar
- org.eclipse.core.variables_3.2.500.v20110928-1503.jar
- org.eclipse.emf.ecore_2.7.0.v20110912-0920.jar
- org.eclipse.emf.ecore_2.7.0.v20120127-1122.jar
- org.eclipse.equinox.frameworkadmin.equinox_1.0.300.v20110506.jar
- org.eclipse.equinox.frameworkadmin.equinox_1.0.300.v20110815-1438.jar
- org.eclipse.equinox.p2.updatesite_1.0.300.v20110510.jar
- org.eclipse.equinox.p2.updatesite_1.0.300.v20110815-1419.jar
- org.eclipse.jdt.compiler.tool_1.0.100.v_B76_R37x.jar
- org.eclipse.jdt.compiler.tool_1.0.100.v_B79_R37x.jar
- org.eclipse.jface_3.7.0.I20110522-1430.jar
- org.eclipse.jface_3.7.0.v20110928-1505.jar
- org.eclipse.ltk.core.refactoring_3.5.201.r371_v20110824-0800.jar
- org.eclipse.ltk.core.refactoring_3.5.201.r372_v20111101-0700.jar
- org.eclipse.pde.runtime_3.4.201.v20110819-0851.jar
- org.eclipse.pde.runtime_3.4.201.v20110928-1516.jar
- org.eclipse.ui_3.7.0.I20110602-0100.jar
- org.eclipse.ui_3.7.0.v20110928-1505.jar
问题是对那些查看文件系统或试图记住数字的人来说，这些数字通常毫无意义。如果处理制品时你用的是P2或OBR（OSGi Bundle Repository）等仓库工具，那这可能并不重要；但世上的大部分构建工具还是需要用Require-Bundle来指定依赖关系的，而且需要明确的版本号和名称。这也让很多OSGi运行时的处理变得复杂，对已安装的Bundle进行比较原本是很简单的，但现在也会变得更加困难。
-SNAPSHOT/release/-SNAPSHOT模型能解决这个问题，因为版本号在推广时肯定是递增的。（这并不排除在敲定版本号之后还会有进一步的测试；但在测试阶段发现的问题通常只会改变补丁的级别。）Apache Felix项目成功运用了这个过程，它们的发布版本都是短数字，在现有的构建系统里也很容易重用。Apache Felix的构建要比Equinox容易一些，原因就是这个模型、以及这些制品在Maven中心库里已经是可用的了。
在InfoQ看来，OSGi错失了良机。OSGi核心平台专家组没有彻底完成方案，原因仅仅是这些相对次要的问题，所以专家组的工具化问题已经变成了人的问题。
