最近リリースされたOSGi Release 5 早期アクセスドキュメントによると、次回の仕様で最も期待されていたフィーチャの1つ、OSGi向けSNAPSHOTスタイルバージョンが 仕様から落とされた 。既存のツール群への懸念のためである。
しかし、既存のツール群、管理とプロビジョニングシステムとのやりとりで、大きな懸念がある。これらのシステムは、プレリリースバージョン文字列を持つバンドルを理解できない。これらがプレリリースバージョンシンタックスを適切にサポートできるようにするには、かなりの変更が必要である。
問題の原因は、空の修飾子(qualifier)を扱う方法が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ビルド、そして 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のようなツールでは、 .qualifierの代わりに「マジック置換値」として -SNAPSHOT を使っている）を開発用に使え、その一連のビルド用のみに 1.2.3をリリースできる。その後は、1.2.4-SNAPSHOTに飛ぶわけである。
不幸にして、持ち上がった懸念は、経験によるものではなく推測によるものだった。
更に我々はまた、プレリリースバージョンの精神的な複雑さについて心配しだした。 CPEG内と仲間内の多くの議論で、バージョンの順序付けとあるバージョンは、ある範囲に含まれる、と人々は混乱するだろう、と言われた。もし我々のような「専門家」が我々の頭の中でスッキリできなければ、他の人達は大変だろうと考えた。
複雑はどのようにビルド範囲が関係しているかによっていた。[1.0,2.0) のような既存のユースケースが考慮された。この場合、1.0はスナップショット1.0-*を許し、もう一方の端である 2.0は許されない。結局、このルールは詰まるところ、もし境界値が入るなら、スナップショットを含み、境界値が範囲外ならスナップショットを含めない、ということである。これは覚えるのに難しくはない。
リスクは、この決定が実際に OSGi生成コンテンツの仕様を止めさせたことである。ほぼ一年間、Eclipseビルトの成果物をMaven名前空間でどのように表現するかの議論があった。コンポーネントをorg.eclipse.*スタイルグループにマップし、完全な成果物名を使ってやろうとした。しかし、この提案は単に 全ての修飾子を落とし て、少なくとも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のようなリポジトリツールを使って自分の成果物を実現するのであれば、どうでもいいことであるが、世界のビルドツールの多くは、明示的なバージョン番号と名前によって、依存性の Require-Bundleタイプを基にして、いまだに作られている。それはまた、多くの OSGiランタイムの管理を複雑にしている。インストールされているbundleの簡単な比較がもっと難しくなっている。
-SNAPSHOT/release/-SNAPSHOT モデルがこの問題を解決している。開発中には、バージョン番号が明示的に増加している（このことは、バージョン番号が最後に決まった後に、更にテストする段階を持つ可能性を完全に消し去ってはいない。しかし一般的には、その段階で問題が見つかると、とにかくパッチレベルに飛ぶことになる）。このプロセスはApache Felix プロジェクトで上手く、使われた。短い番号を使ってリリースのリスト を持ち、既存のビルドに再利用するのが簡単である。ほぼ間違いなく、 Equinoxより 頭に何もついていないOSGiビルドには、Apache Felixのようにビルドするのは、易しい。このこととMavenセントラルでは既に成果物が入手できることの両方が理由である。
InfoQの意見では、これは逃された機会である。提案された実装をやり遂げずに、取るに足らない懸念を基に、OSGi コアプラットフォームの専門グループは、ツール問題を人の問題にしてしまった。