Mastering modularity - OSGi in Action - page 38

This is the complete identification metadata for the public API bundle. The identifica-
tion metadata for the other paint program bundles are defined in a similar fashion.
Now that bundle identification is out of the way, we're ready to look at code visibility,
which is perhaps the most important area of metadata.

OSGi version number format
One important concept you'll visit over and over again in OSGi is a version number ,
which appears here in the bundle-identification metadata. The OSGi specification de-
fines a common version number format that's used in a number of places throughout
the specification. For this reason, it's worth spending a few paragraphs exploring ex-
actly what a version number is in the OSGi world.

A version number is composed of three separate numerical component values sepa-
rated by dots; for example, 1.0.0 is a valid OSGi version number. The first value is
referred to as the major number , the second value as the minor number , and the third
value as the micro number . These names reflect the relative precedence of each com-
ponent value and are similar to other version-numbering schemes, where version-num-
ber ordering is based on numerical comparison of version-number components in
decreasing order of precedence: in other words, 2.0.0 is newer than 1.2.0, and 1.10.0
is newer than 1.9.9.

A fourth version component is possible, which is called a qualifier . The qualifier can
contain alphanumeric characters; for example, 1.0.0.alpha is a valid OSGi version
number with a qualifier. When comparing version numbers, the qualifier is compared
using string comparison. As the following figure shows, this doesn't always lead to
intuitive results; for example, although 1.0.0.beta is newer than 1.0.0.alpha, 1.0.0
is older than both.

Higher version

1.0.0 1.0.0.alpha 1.0.0.beta 1.0.1 1.1.0 1.1.1 1.2.0

OSGi versioning semantics can sometimes lead to non-intuitive results.

In places in the metadata where a version is expected, if it's omitted, it defaults
to 0.0.0. If a numeric component of the version number is omitted, it defaults to 0,
and the qualifier defaults to an empty string. For example, 1.2 is equivalent
to 1.2.0. One tricky aspect is that it isn't possible to have a qualifier without speci-
fying all the numeric components of the version. So you can't specify 1.2.build-59;
you must specify 1.2.0.build-59.

OSGi uses this common version-number format for versioning both bundles and Java
packages. In chapter 9, we'll discuss high-level approaches for managing version
numbers for your packages, bundles, and applications.