Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Major versoin
  2. Minor version
  3. Incremental version (bugfix)
  4. Build number
  5. A Qualifier.

Reference: OSGi version and version range schemes are available in the Core OSGi spec, which can be downloaded here(see §3.2.4 and §3.2.5 on page 38 of OSGi Service Platform Release 4 Version 4.1 Core Specification pdf)

Flaws

Other than the limitation of supported versions, the current implementation has several flaws:

...

  • 1-beta ==? 1-abc: "2" ==? "7-abc" -> 1-abc is newer
  • 1.0 ==? 1.0-abc: "4" ==? "7-abc" -> 1.0-abc is newer
  • 1.0-alpha-10 ==? 1.0-alpha-2: 10 > 2, so '1.0-alpha-10' is newer
  • 1.0-alpha-1.0 ==? 1.0-alpha-1: equal
  • 1.0-alpha-1.2 ==? 1.0-alpha-2: 1.0-alpha-2 is newer

Make version handling pluggable

Note: This approach differs from the version comparison as done by OSGi [0].

Make version handling pluggable

When somebody devices a version scheme that cannot be handled by the above, it should be possible to plug in a new scheme. Two possible scenarios for unsupported schemes:

...


This scheme doesn't even come close to being able to describe the variety of version schemes supported by my proposal.
Perhaps it's better if, when we do XML, we use XSD to describe the version schemes.
We define a set of simple/complextypes that people have to extend, and the engine can then convert it to a parser/verifier/order implementation/representation using the base classes.
The parser would use the 'prefix' values and the type attributes to determine what kind of token is next, in the version string. It would then build an XML DOM that can be validated against the XSD, which can have extra rules.
Anyway, UDDI tried to do something similar for random applications - to have the API specs in a uniform format so you could generate an application around reusable components, but that didn't work out and AFAIK the specs are just human readable documents. If somebody wants to create a parser/validator/sorter for a version spec, there should just be enough documentation for them to do it.





References and Related Material

Wiki Markup
<ac:structured-macro ac:name="anchor" ac:schema-version="1" ac:macro-id="4456db41-1e6a-435d-b8f8-5c74cdc33507"><ac:parameter ac:name="">osgi</ac:parameter></ac:structured-macro> \[0\] [OSGi Service Platform Release 4 Version 4.1 Core Specification|http://www.osgi.org/Release4/Download], §3.2.4 "Version" and §3.2.5 "Version Ranges" on page 38, §3.5.3 "Bundle-Version" on page 46, §6.1.26.5 "Version.compareTo()" on page 200