Efforts/Package Restructuring/Versioning

Traditionally, OOo and derived products have a three number Version ID as well as a Build ID. 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.

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 build ID is used to know different builds of basically the same version, which may differ by some bugfixes, while it seemed to minor to increase the minor version number.

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 (e.g. 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 number to a predefined product. Also see issue 94693.

Example

For obvious reasons, these three layers need to be versioned independently. The following example therefore gives the versions of the three layers, showing the conflict with the traditional approach.

An OOo 3.1.3 may be installed as the following layers:

• URE: URE 1.4.1 into ".../openoffice.org/ure"
• Basis: Basis 3.0.2 into ".../openoffice.org/basis3.0"
• Brand: OOo 3.1.3 into ".../openoffice.org3"

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

• URE: URE 1.6.7 into ".../openoffice.org/ure"
• Basis: Basis 3.0.5 into ".../openoffice.org/basis3.0"
• Brand: SO 9.1.10 into ".../sun/StarOffice9"

Leading to the following installed layers:

• URE 1.6.7 into ".../openoffice.org/ure"
• Basis 3.0.5 into ".../openoffice.org/basis3.0"
• Brand: OOo 3.1.3 into ".../openoffice.org3", SO 9.1.10 into ".../sun/StarOffice9"

As can be seen above, the now installed "OOO 3.1.3" differs from the originally installed one by the URE Layer and the Basis Layer. Consequently, reporting only the version numbers 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 Layer and the Brand Layer 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 defining appropriate dependencies: - Brand Layer to Basis Layer: A particular Brand Layer depends on a Basis Layer, recording the Basis major and minor version numbers in the dependency. - Basis Layer to URE Layer: 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 only, which defaults to "1" if no version number has been defined explicitly.

Solution

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

"OOo Brand 3.1.3 - Basis 3.0.2 - URE 1.4.1"

Optimizations

The above composed version string seems to be rather longish and unhandy. Two different optimizations may be applied to make this string more handleable:

• Use dependency constraints, to remove implicitly defined version numbers.
• Use defaults, to leave out version numbers which match the default.

Dependency Constraints

As any Brand Layer directly records the major and micro versions of the Basis Layer in its dependencies, the Basis Layer of any particular Brand Layer may only vary within 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 URE Layer and Basis Layer, 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.

By applying this knowledge, some parts of the above rather longish version number may be left out, leading to

"OOo 3.1.3 - 0 - 4.1"

where

• "OOo 3.1.3" is the Brand Layers version and name, while
• "0" is the the micro version of the Basis Layer, while
• "4.1" is the minor and micro of the URE.

Or in principal

• URE a.b.c
• Basis d.e.f
• Brand <name> g.h.i

Results in

"<name> g.h.u - f - b.c"

Defaulting

Most parts of an installed OOo are going into the Basis Layer respectively into the URE Layer. Instances of the Brand Layer are unlikely to be versioned in their micro number, thus this micro number is going to be "0" most of the time. Same approach may be applied to the URE and the Brand Layer. For example, if a minor or micro version number is zero, it may be left out in the version string.

Take a look at this example, where some minor and micro version numbers are zero:

• URE 1.4.0
• OOo Basis 3.1.0
• OOo Brand 3.0.0

Leaving out the zeros in the versioning string, while still applying the dependency constraints gives

"OOo 3--4"