Efforts/Package Restructuring/Versioning

Traditionally, OOo and derived products have a three number version ID as well as a build ID. For example

• OOo version "2.3.0" is the OOo major version "2", feature level "3", bugfix level "0", while
• OOo version "2.4.1" stands for major version "2", feature level "4", bugfix level "1".

The parts of the version ID are called

• major - reflecting incompatible or "big" changes,
• minor - showing that enhancements or features have been added,
• micro - expressing that bugfixes have been applied.

Problem

Starting with OOo 3, the OOo product is going to consist of three layers, allowing to share and to re-use the two lower layers between different products and brands. The three layers are

• the URE, providing the Component model as well as the core system abstraction,
• the Basis, bringing the applications, the framework etc., basically everything which does not belong into URE and which is "brand" independent,
• the Brand, which is everything being brand specific, such as the brand's name, the starter (soffice) as well as logos, readmes etc.

Because of this sharing, the two lower layers of an installed product may be updated by other products and therefore need to be dynamically reflected in a products about box respectively version number, which conflicts with the traditional approach of assigning to be a predefined product.

Example

For obvious reasons, these three layers are basically versioned independently. For one of the next OOo 3 versions the actually installed layers may be:

An OOo 3.1.3 may be installed as the following layers:

• URE: URE 1.4.1
• Basis: Basis 3.0.2
• Brand: OOo 3.1.3

While later on an StarOffice 9.1.10 may be installed, which may consists of

• URE: URE 1.6.7
• Basis: Basis 3.0.5
• Brand: SO 9.1.10

Leading to the following installed layers:

• URE: URE 1.6.7
• Basis: Basis 3.0.5
• Brand: OOo 3.1.3 , SO 9.1.10

As can be seen above, the now installed "OOO 3.1.3" differs from the originally installed one by the URE and Basis layers. Consequently, reporting only the version of the Brand layer e.g. in the about box is not sufficient and may lead unclear bug reports etc.

Compatibility

URE versions are expected to stay compatible with minor and micro versions, e.g. a client using an URE 1.3.2 may very well use an URE 1.4.5 without the need to change. The interface between the Basis and the Brand is expected to be less stable, concretely we expect it to break with minor changes but not with micro changes (which are for bug fixes only anyway). That means that a Basis 3.1 may not be compatible with a Basis 3.0. Consequently we express these compatibility expectations by using appropriate dependencies: - Brand to Basis: A particular Brand layer depends on a Basis layer while recording the Basis major and minor version numbers in the dependency. - Basis to URE: A particular Basis layer only depends on an UREs major version number, which per definition only changes if becoming incompatible. Any incompatible URE change will be reflected by adding a major version number to the URE, e.g. URE2, thus a Basis layer's dependency records the UREs major version number, which defaults to "1" if no version number has been recorded.

Solution

The version ID of a particular OOo or derived product consequently has to be created out of the version numbers of its layers, e.g.

"OOo Brand 3.1.3-OOo Basis 3.0.2-URE 1.4.1"

Optimizations

As any brand layer directly records the major and micro versions of the basis layer in its dependency, the basis layer of any particular Brand layer may only vary with the micro version of the Basis layer. That means, providing the micro number of the Basis layer only, e.g. in the version string, is sufficient. Similar with the URE and Basis, the URE for a particular Basis may only vary in its minor or micro version numbers, thus providing the minor and micro numbers of the URE is sufficient again.

Some parts of this rather longish version number may be left out, leading to

"OOo 3.1.3-0-4.1"

where

• 3.1.3 stands for the brand layer version, while
• 0 is the the micro of the Basis layer, while
• 4.1 is the minor.micro of the URE.

Minor or micros numbers may be defaulted to zero, and left out in the version string if the actual value matches the default (zero). E.g.

• URE 1.4.0
• OOo Basis 3.1.0
• OOo Brand 3.0.0

Leading to

"OOo 3-1-4"