Release Model

OpenOffice.org Release model

Features releases will happen every 6 months. Bugfix release for important issues will be happen as a maintenance release 3 months after each feature release.

We will have a continuously available code line that currently is called "SRC680". Developers can hand over their CWS to QA and the CWS will be integrated as soon as it is approved by QA. Every 6 months we will create a new branch for a feature release ("OOn", n=A,B,C...) and call the first build on this branch "beta". This point in time will also be the UI and Feature freeze date for this release. On this branch we proceed as we do nowadays: have a code freeze, release candidates etc.

Once the release is done we will keep this branch open and add a selected number of bug fixes (show stoppers found late, regressions) that together make up the maintenance (micro) release that is created 3 months after the feature release. After this release the branch will be closed for regualar bug fixes. New features should be added on this branch only in very exceptional cases (means: there must be a very important reason that has a broad acceptance). Important security fixes could be done in a further micro release on this branch in urgent cases.

An "OOn" branch will exist for 3 months+x (x being the time we will have between the feature freeze date and the release date of the next feature release). As we will try to keep the work load on this branch very low (at least in the 3 months after the feature release) it looks feasible even from a release engineering perspective. We should be able to avoid the problems we had when we had to maintain two diverging code lines for OOo 1.1.x and OOo 2.0 Beta for a very long time.

In the meantime we can integrate new features or other bug fixes on the "main trunk" SRC680 towards the next feature release. Once the feature freeze date for the next release is reached the games starts again.