OX6:Update to 6 22

Update Portal Open-Xchange Server v6.22

The new Open-Xchange Server v6.22 provides the first preparation on the way to the next Generation Open-Xchange Server 7. With the new update, there is released a new improved Open-Xchange Server Backend with many preparation and new enhancement for both generations.

Especially on the Backend, Open-Xchange implemented some changes and improvements like housekeeping of configuration files and packages, improved exception framework, unified OSGi, etc.

This Portal provides an overview about the different requirements, update guides and changes of Open-Xchange v.6.22 in compare to the Backend of Open-Xchange 6.20.x.

Please read the different articles and manuals regarding the update. We encourage administrators of Open-Xchange 6 v6.20.x to install this update.

Requirements and Server / Frontend Combinations

Abbreviation	Meaning	Comparison
<generation>	The first number is the product generation number. A new generation may contain new architecture, different technology and many more.	OX 6
<major release>	The second version number (major release) indicates significant program changes in terms of added functionality. Major changes to design and enhancements of APIs are possible. All APIs shall be backward compatible, which means, that mainly new functions can be added. If Open-Xchange releases a new major release this will be an even number, unstable interim releases have odd numbers.	6.10
<minor release>	The third version number (minor releases) indicates an update with consolidated bug fixes and non-intrusive feature enhancements. APIs and database will not be changed if this can be avoided. All changes must be backward compatible.	6.10.1
<build number>	The Rev-number (Revision) shows the progress of the development in single steps	6.10.1-Rev3
Public Patch Release / Patch Release	A Public Patch Release enables Open-Xchange to publish a feature together with a patch. This in turn enables Open-Xchange to react more flexibly to time requests for certain features, thus relieving minor releases and making it possible to shift them. Delivering a feature with a Public Patch Release requires: It can be implemented without far-reaching side effects. This is especially true for features that are implemented as plug-ins. To a limited extend, features affecting a limited sub set of core functionality can be included. Technical pragmatism is fine to reach the goal (e.g., copy & paste of functionality instead of abstraction into a service). This pragmatism has to be leveled out though as soon as the feature is ported into a more flexible branch. It can be deactivated and is deactivated by default. If a customer installs a Public Patch Release, the familiar feature set does not change. Only if explicitly activating the enhanced features, will they be available to the end user. If features require changes to the data base schema or configuration files, they have to be developed in such a way that they do not impair the running system. Side-effects of Public Patch Releases are evaluated by the respective developers. Together with the QA team, they make a test plan for checking for those side effects and other effects.