|
|
| Line 1: |
Line 1: |
| {| border="1" cellpadding="3" cellspacing="0" | | {| border="1" cellpadding="3" cellspacing="0" |
| !align="left" |Abbreviation | | !align="left" |Old package(s) |
| !align="left" |Meaning | | !align="left" |New package |
| !align="left" |Comparison
| |
| |- | | |- |
| |<generation> | | |open-xchange-common |
| |The first number is the product generation number. A new generation may contain new architecture, different technology and many more. | | |open-xchange-osgi |
| |<font color="#008000">OX 6</font><font color="#FF0000"></font>
| |
| |- | | |- |
| |<major release> | | |open-xchange-activation |
| |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.
| | | |
| |<font color="#008000">6.10</font><font color="#FF0000"> </font>
| |
| |-
| |
| |<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.
| |
| |<font color="#008000">6.10.1</font><font color="#FF0000"></font>
| |
| |-
| |
| |<build number> | |
| |The Rev-number (Revision) shows the progress of the development in single steps
| |
| |<font color="#008000">6.10.1-Rev3</font><font color="#FF0000"></font>
| |
| |- | | |- |
| | | | | |
| | | | | |
| | | | |– |
| |-
| |
| |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.
| |
| |
| |
| |} | | |} |