By Michael Stucki
Version 1.0
Intended Audience
This document describes the release workflow of TYPO3. It is based on the results of a very fruitful discussion at the first official Core team meeting which took place at August 10, 2006, in Dietikon/Switzerland.
The goal of this document is to make the release process more transparent to both developers and customers. It will also help to assure that deadlines can be kept more accurate in future.
Version numbers and what they say
TYPO3 follows the principle of major.minor.patch versions which is explained very detailed in the Free Software Project Management Howto: http://www.tldp.org/HOWTO/Software-Proj-Mgmt-HOWTO/starting.html#CHOOSEVERSIONING
In short, there are three types of new versions:
Version type: | Major versions (e.g. TYPO3 5.0) | Minor versions (e.g. TYPO3 4.1.0) | Patch versions (e.g. TYPO3 4.0.2) |
New features | ++ | ++ | no features! |
Bugfixes | ++ | ++ | ++ |
Changes to the coding API / architecture | ++ | (+) | no changes! |
Changes to the TYPO3 configuration (includes TypoScript) | + | (+) | no changes! |
Changes to the database | + | + | no changes! |
Summary: With the exception of changes to configuration and coding API, major and minor versions are treated very similar. It is not explicitly defined that minor versions must not contain any feature changes, but chances that this happens are much smaller.
Releases vs. Branches
For every major and minor version, a new branch will be opened in which the release will be developed separately to the very upstream development version (which is called to be Trunk).
This allows the development of multiple versions at the same time.
While a release is an identical snapshot of a version, each branch can contain many such releases. Since branches are declared by their major and/or minor version number, releases inside of one branch can only differ at their patch version number. Consequently, the final release of a major or minor version is treated as the version with patch version 0.
Some examples may clarify this scheme:
Release name | Version number | Branch | Major version | Minor version | Patch version |
TYPO3 4.0 | 4.0.0 | 4.0 (TYPO3_4-0 in Subversion) | 4 | 0 | 0 |
TYPO3 4.0.1 | 4.0.1 | 4.0 (TYPO3_4-0 in Subversion) | 4 | 0 | 1 |
TYPO3 3.8.1 | 3.8.1 | 3.8 (TYPO3_3-8 in Subversion) | 3 | 8 | 1 |
The branch of the most recent final version is called to be the “stable branch”. Additionally to that, there are “outdated” (not supported anymore) and “unstable” (no final version available yet) branches.
Definition of development phases
Every release is stepping through different development phases. This is an explanation of them, it also defines who is responsible for them:
Phase | Description | Responsibility |
Planning | Team building: Recruiting of developers, team leader, other supporters | Research & Development Committee |
Brainstorming | Definition of goals and wishes | Project leader |
Coding | Probably the longest phase: Implementation of the goals which have been defined | Project leader |
Beta | The product is usable, but probably not stable enough. Requesting feedback from testers. APIs might still change. | Project leader |
Feature freeze | No additional feature changes/additions are allowed. Project leader transfers responsibility to Release manager. | Project leader |
Release candidate (RC) version | A release candidate is a candidate of the final version. If no important bugs are found, this will become the final version. Otherwise, more release candidates will be released after the same principle. | Release manager |
Final version | Release of a stable version | Release manager |
Release workflow
Major and minor versions
The project manager leads the development phases up to (including) the beta release. He also takes care of communication, status reports (writing news, etc.) and release of test versions (alpha, beta, etc.)
Starting with the first release candidate, the release maintainer (version independent) becomes accountable for this release. He will assure that no further features will be added but all important bugs will be fixed. He will probably still depend on the help and know-how of the development team.
Patch versions
The Core team is permanently fixing problems in the development branch of this version.
Two days before the end of each calendar month, the release manager polls the Core team and asks if a new version is worth to be released. This depends much on the amount and importance of bugs which have been fixed meanwhile.
This polling phase will last for two days.If the team votes to release a new version: Start RC phase immediately, no further changes are allowed except urgent bugfixes. The RC phase will last for 1 week, more RCs may extend it of course.
Finally, the new patch version is released and phase 1 will start again.
There won't be a new poll for at least one month.
Release lifecycle
Since a release version is just a snapshot of a version (see above), updates are provided per branches. Each update contains the branch number, appended with the patch version number.
Currently, TYPO3 provides updates only for the most recent stable branch. Older branches become “outdated” and are not supported anymore. Currently this means that only the branch “TYPO3_4.0” is supported with updates, however this situation may change in near future...
Links & other resources
Discussion of TYPO3 release numbering scheme:
http://lists.netfielders.de/pipermail/typo3-dev/2004-April/thread.html#2610
Free Software Project Management Howto:
http://www.tldp.org/HOWTO/Software-Proj-Mgmt-HOWTO/
This document is published under the Open Content License available from http://www.opencontent.org/opl.shtml
The content of this document is related to TYPO3 - a GNU/GPL CMS/Framework available from www.typo3.com
   |
