Page History

...

I'm proposing the following implementation: GenericArtifactVersion.java (unit test: GenericArtifactVersionTest.java). It has been integrated in artifact 3.0-SNAPSHOT r656775as ComparableVersion.java.

Features:

• Mixing of '-' and '.' separators
• Transition between characters and digits also constitutes a separator:

  • Wiki Markup
    1.0alpha1 => \[1, 0, alpha, 1\]; This fixes '1.0alpha10 < 1.0alpha2'

• Unlimited number of version components
• Version components in the text can be digits or strings
• strings are checked for well-known qualifiers and the qualifier ordering is used for version ordering
  • well-known qualifiers (case insensitive)
    • snapshot (NOTE; snapshot needs discussion)
    • alpha
    • beta
    • rc
    • (the empty string)
    • ga
    • sp
• version components prefixed with '-' will result in a sub-list of version components.
  A dash usually precedes a qualifier, and is always less important than something preceded with a dot.
  We need to somehow record the separators themselves, which is done by sublists.
  Parse examples:

  • Wiki Markup
    1.0-alpha1 => \[1, 0, \["alpha", 1\]\]

  • Wiki Markup
    1.0-rc-2 => \[1, 0, \["rc", \[2\]\]\]

...

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:

...

I'm not entirely sure this is necessary, but for other languages that cannot use pre-packaged version scheme implementations in Java,
we need to have some sort of metadata, preferrably in the version-scheme artifact, describing the version scheme. Perhaps something like
version-scheme-1.0.jar!/META-INF/maven/version-scheme.file-extension 

...

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.