Release Workflow

Version 1.1 by Michael Stucki

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:

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:

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:

Release workflow

Major and minor versions

  1. 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.).
  2. 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

  1. The Core team is permanently fixing problems in the development branch of this version.
  2. 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.
  3. 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.
  4. Finally, the new patch version is released and phase 1 will start again.
  5. 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...

Platform support

TYPO3 CMS is working on every platform which supports PHP and other (optional) tools.
Within a stable release, no changes that break compatibility to the software requirements must be added.

New releases may break the compatibility of software requirements if there is a good reason for it. Such changes should be announced on the Core Team mailing list before they are committed.

New releases should always be compatible with the latest stable (LTS) version of the following Linux Operating Systems:

Debian, Ubuntu, CentOS, Redhat. (These are the 4 most used Linux Operating Systems for web hosting as of March 2013. Source: http://w3techs.com/technologies/history_details/os-linux)

Other platforms (Windows, MacOS) usually don't have 3rd party software (like PHP, MySQL) bundled with the operating system. It can be installed independently using the latest available version.

The website of http://distrowatch.com/ offers a nice overview about operating systems and their shipped package versions.

Links & other resources

Discussion of TYPO3 release numbering scheme: http://lists.typo3.org/pipermail/typo3-dev/2004-April/thread.html#2610

Free Software Project Management Howto: http://www.tldp.org/HOWTO/Software-Proj-Mgmt-HOWTO/

Revision history

  • 1.0 - August 2006: Initial document
  • 1.1 - August 2013: Add section on Platform support