OSGi and the enterprise—why now? - Enterprise OSGi in Action - page 13

Although our explanation focuses on the API , it isn't only packages that should be
semantically versioned. The versions of bundles also represent a promise of functional
and API compatibility. It's particularly important to remember that semantic versions
are different from marketing versions . Even if a great deal of work has gone into a new
release of a product, if it's backwards compatible the version would only change from,
for example, 2.3 to 2.4, rather than from version 5 to version 6. This can be depressing
for the release team, but it's helpful for users of the product who need to understand
the nature of the changes. Also, think of it this way—a low major version number
means you don't make a habit of breaking your customers!
Guarantees of compatibility
One of the benefits provided by the semantic versioning scheme is a guarantee of
compatibility. A module will be bytecode compatible with any versions of its depen-
dencies where the major version is the same, and the minor version is the same or
higher. One warning about importing packages is that modules should not try to
import and run with dependencies with lower minor versions than the ones they were
compiled against.
Forward compatibility
Version ranges are important when importing packages in OSGi because they define
what the expected future compatibility of your bundle is. If you don't specify a range,
then your import runs to infinity, meaning that your bundle expects to be able to use
any version of the package, regardless of how it changes! It's good practice to always
specify a range, using square brackets for inclusive or parentheses for
exclusive versions. For example, [1.1,2) for an API client compiled against a pack-
age at version 1.1 would be compatible up to, but not including, version 2.
Coexistence of implementations
The most significant benefit provided by versioning is that it allows different versions
of the same module or package to coexist in the same system. If the modules weren't
versioned, there would be no way of knowing that they're different and should be iso-
lated from one another. With versioned modules (and some classloading magic cour-
tesy of OSG i), each module can use the version of its dependencies that's most
appropriate (figure 1.5).
As you can see, being explicit about dependencies, API , and versioning allows
OSG i to completely obliterate classpath hell, but OSG i on its own doesn't guarantee
well-structured applications. What it does do is give developers the tools they need to
define a proper application structure. It also makes it easier to identify when applica-
tion structures have slid in the direction of highly coupled soupishness. This is a
pretty big improvement over standard Java, and OSG i is worth considering on the
basis of these functions alone. OSG i has a few more tricks up its sleeve. Curiously
enough, modularity was only one of the aims when creating OSG i: another focus was
dynamic runtimes.