Java Reference
In-Depth Information
There's a price to pay for this flexibility. Versioning must be done as a core task
throughout the development process, not as an afterthought. Versioning packages and
maintaining a versioning policy is a lot of work. One easy way to reduce the amount of
work is to have less to version. In OSG i, you have the option to not expose the imple-
mentation packages of a bundle (assuming that no other bundle needs them). As a con-
sequence, the simplest option you have is to not export packages to avoid the need to
version them. When you need to export packages, then you need to version them. Let's
look more closely at how you can implement a versioning policy for packages in OSG i.
9.1.2
Package versioning
Let's consider a package named org.foo with a version of 1.0.0.r4711 provided by a
bundle called foo that is itself at version 1.0.0 . Its manifest looks like this:
Bundle-ManifestVersion: 2
Bundle-SymbolicName: foo
Bundle-Version: 1.0.0
Export-Package: org.foo;version:="1.0.0.r4711"
As we mentioned previously, the OSG i specification doesn't define a versioning policy,
which means you can use any scheme that makes sense to you. But the OSG i specification
does recommend the following policy behind version-number component changes:
Major number change —Signifies an incompatible update
Minor number change —Signifies a backward-compatible update
Micro number change —Signifies an internal update (such as a bug fix or perfor-
mance improvement)
Qualifier change —Signifies a trivial internal change (such as line-number
refactoring)
This is a common version compatibility policy. Why? Versions are important for the
consumer to specify what's needed, and this policy makes it possible to easily express a
floor and a ceiling version in between which all versions are acceptable. As you saw in
chapter 2, a version range is expressed as a pair of version numbers inside braces or
parentheses. This follows mathematical interval notation, where a square brace signi-
fies an inclusive value and a parenthesis signifies an exclusive value. As an example,
consider a typical definition of a package import:
Import-Package: org.foo;version:="[1.0,2.0)"
The org.foo package is imported from version 1.0.0 up to, but excluding, 2.0.0 .
This makes sense if the recommended version policy is being used, because it includes
all backward-compatible versions and excludes all non-backward-compatible versions,
which a change in the major number would signify. Being able to specify such ranges
is useful because the import can be satisfied by a wider range of exports. This scheme
works only if producers and consumers operate with a shared understanding of the
kind of compatibility being expressed by a given version number.
Search WWH ::




Custom Search