Release Workflow TYPO3 CMS
This document describes the release workflow of TYPO3 CMS. It is based on the results of the change proposed and approved in this Blueprint in 2014.
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.
LTS - Long Term Support
- A new LTS is released every 1,5 years.
- Support time for a particular LTS version is 3 years after its release.
In the time between LTS versions:
- Stable snapshots will be created regularly with all features considered "stable" at the time of the release.
- These releases are called "Sprint Releases" (minor releases).
- Those releases usually won’t have minor patch level releases, only in case of security or important bug fixes.
- Projects using these releases will need to update to the "next" sprint release whenever it is available.
- LTS uses the major number. The current LTS version is TYPO3 v8 (under the hood it's 8.7.x). The next LTS path will start with 9, after that with 10 and so forth.
- Sprint releases use the minor number, so first snapshot is 9.0.0, next one is 9.1.0 and so forth.
- The final LTS release uses the last snapshot number (e.g. 9.23).
- LTS bugfix releases use the usual patch level number, e.g. 9.23.1 LTS, 9.23.2 LTS, ...
- If a security fix needs to be integrated, a patchlevel release will be added based on the last sprint release (i.e. 9.2.1). The next release is then still "8.3.0" (which of course also includes the security fix from 9.2.1).
- The versioning scheme is best described and explained by Fear-Driven Versioning, thus it's different to a strict Semantic Versioning but tries to follow those principles as much as possible.
|… time and release sprints pass by …|
|kick-off phase||Starts right after a LTS release and prepares for the first release of the next major version, system requirements are defined and components marked to be deprecated in earlier versions are removed.|
|sprint phase||Stable phase where new minor releases are published|
|stabilization phase||a version is considered to be finished, no more new features are allowed, the focus is on stabilization and bugfixes only, release candidates are published|
- Starts right after a LTS was released (i.e. after the 8 LTS release).
- Supported browser and minimum system requirements for the next major version are decided.
- Special tasks required in preparation for the next major new release (i.e. 9.0.0) - i.e. removing deprecated code.
- Release is prepared just like the sprint phase described below.
After every minor release:
- a "merge window" for features opens for a short while.
- a "feature freeze" is declared, starting a stabilization phase.
- If a merged feature turns out to be not ready yet, it can be reverted again and has a chance for next sprint release (minor release)
- after stabilization the sprint release is packaged and announced.
- repeat process from 1)
LTS Stabilization phase
- a version is considered finished
- no more new features are allowed
- the focus is on stabilization and bugfixes only
- release candidates are published
- a time-frame of 2-4 months prior to the planned final release is chosen to declare the "stabilization phase" (features are still allowed if they are missing and really required - that's a difference to the old "feature freeze phase")
Code components can be deprecated until the stabilization phase. Those components will be removed in the kick-off phase of the following major version.
- A method gets deprecated in 8.3.0
- The method will still be available within TYPO3 v8 LTS
- The method gets dropped in 9.0.0
Deprecated code from older major versions can still be removed after the kick-off release (first ".0" minor release of the next version).
- Method deprecated in 8.2.
- Was not removed right away in time for 9.0.0.
- Can be removed in 9.2.0.
So no deprecated code from previous major versions should be used in production, as it can be removed any time!
Code that is marked to be deprecated during the development of TYPO3 CMS 8 will not be removed during the whole 8 live-span.
Definition of a "Breaking Change":
- Change or removal of public API (see "Definition of Public API" below).
- Change of minimum system requirements (i.e. PHP, MySQL, Webserver, etc).
Breaking changes are allowed in major version upgrades (i.e. "8.2" to "9.0.0").
- Breaking changes are allowed if there is a compatibility layer (turned on by default) or a feature switch (turned off by default).
- Breaking changes which provides an automated migration path (i.e. to adapt files, database or settings) are allowed.
- Breaking changes without an automated migration path require a textual migration documentation, and should be discussed with the TYPO3 Core Team Leader before being included. Especially security issues might need to use this path.
Definition of "Public API"
- Components which are "stand alone" and not meant to be extensible are not considered Public API (i.e. Install Tool, Extension Manager, Scheduler Backend Module).
- Signal-Slots and Hooks are Public API.
- Methods and properties in PHP classes: In an ideal world all methods and properties that are public API would be tagged with "@api". In TYPO3 historically older classes have most methods public and potentially extensible. So considering if something is "public API" needs to follow common sense. In doubt, the decision is made by the TYPO3 Team Lead.
- For new classes, it should be made clear from the start what is "@api" and what is "@internal".
When selecting the new minimum system requirements for a next major version, the following is taken into consideration:
- Benefits when rising minimum requirements for developers and system administrators (usage of new features).
- Considerations of the whole lifespan of the product, meaning keeping the minimum requirements for the next four years, and considering the effort to backport to older versions by then.
- Release schedule and maturity from upstream packages (i.e. PHP, MySQL)
- Current technical availability of the upstream packages for major distributions (Debian, Ubuntu, CentOS, RedHat) as well as development environments (Xamp, Homebrew, etc)
- 1.0 - August 2006: Initial document
- 1.1 - August 2013: Add section on Platform support
- 2.0 - November 2014: Reworked based on Release Cycles blueprint
- 2.1 - November 2015: Adjusted based on workflow done for CMS 7 LTS development cycle, changed number scheme to v8
- 2.2 - May 2017: Changed number scheme to v9