All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh


From TYPO3Wiki
Jump to: navigation, search

<- Back to blueprints overview

Blueprint: Releases

Proposal Adapt release cycles and system for post 6.2 era
Owner/Starter TYPO3 CMS Team
Participants/Members Oliver Hader, Helmut Hummel, Ernesto Baschny, Thomas Maroschik, Matthias Schreiber, Christian Kuhn
Status Draft, Discussion, Voting Phase, Accepted, Declined, Withdrawn
Current Progress Unknown, Started, Good Progress, Bad Progress, Stalled, Review Needed, DONE
Topic for Gerrit -

Target Versions/Milestones

  • Started during TYPO3 CMS Active Contributor Meeting Nuernberg 3/2014
  • First paperwork done on notes in 4/2014
  • Blueprint creation, discussion phase on core list in 5/2014
  • Discussion in team during the T3DD14 in Eindhoven June 20th, 2014, finalized Blueprint.
  • Voting started on July, 27, 2014:
  • Voting withdrawn and blueprint back to draft mode on August 5th 2014 (voting results got distorted)
  • 2014-08-13 Status set to stalled after final voting was turned down and nobody is currently working on anything. Regular "half year" release cycle seems not to happen at the moment, too.
  • 2014-09-07 Blueprint has been overworked and clearified. The term "EAR" has been removed and replaced by "sprint release" which is just a minor release being published more frequently during the development phase for TYPO3 CMS 7
  • 2014-09-10 Blueprint has been accepted during T3ACME14MUC

Goals / Motivation

Major goal is to provide a cleaner, understandable, less stressing and more consistent release cycle for the TYPO3 CMS product after the 6.2 LTS release. The new release concept should provide benefits for agencies, developers and the project at the same time.

Current state

Current release cycles since 2011 works like this:

  • An LTS release every 3 years that is supported until ~ 1 year after release of next LTS
  • Further stable releases in between every half year, supported for ~ 1 year

Comparing pros and cons of the current release cycle:

  • pros
    • good reliability and marketing perspective for agencies on using LTS
    • long term support for smaller customers with no need for new features
  • cons
    • low adoption rate of non LTS releases
      • about 65-70% use LTS versions (source
      • adoption rate of LTS releases is good, many sites stick to this version
      • huge efforts for upgrading required since the lack of know-how from intermediate versions
      • missing feedback from the broader user-base on features being part of intermediate versions
      • due to customers demand for LTS project evolution towards using new features is hindered
    • (self-made) pressure and too high expectations for the developing team prior to LTS
      • new features need to be available until feature freeze
      • new features need to be well tested and rock solid
      • upgrade path needs to be available
      • features not being part of an LTS release might need to wait further 3 years to be adopted

Current target audience of the product is split in two groups:

  • One group sticks to LTS only. If a project is started, the latest LTS version is picked, all development is done on this version and the project is only upgraded if its support cycle comes to an end.
  • Another smaller group uses younger stable releases, with the drawback that those projects may have to go through time consuming upgrades more often. As advantage, those projects can use newer framework structure and features earlier.


Adapt release cycles and improve upgrade paths:

  • A new LTS is released every 1,5 years. Support time for a particular LTS version is 3 years.
  • For 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)
    • Will usually not have minor patch level releases, only in case of security releases.
    • Projects using these releases will need to update to the "next" sprint release whenever it is available.
      • To do so, TYPO3 CMS core will help with a better automated upgrade system.


Agile Release Cycle versions
Release Cycles TYPO3 after TYPO3 CMS 6.2
  • LTS uses the major number, next LTS path will start with 7, after that with 8 and so forth.
  • Sprint releases use the minor number, so first snapshot is 7.0.0, next one is 7.1.0 and so forth.
  • The final LTS release uses the last snapshot number (e.g. 7.23.0). Side note: there is no drawback when declaring a certain number internally as "LTS", as it's just like today, where "4.5" or "6.2" were simply declared "LTS".
  • LTS bugfix releases use the usual patch level number, e.g. 7.23.1 LTS, 7.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. 7.2.1). The next release is then still "7.3.0" (which of course also includes the security fix from 7.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.


  • 7.0.0
    • first minor release for TYPO3 CMS 7
    • system requirements are defined and components marked to be deprecated in earlier versions are removed
  • 7.1.0
    • minor release containing results of recent release sprint, focused on prioritized topics
  • 7.1.1
    • security release based on TYPO3 CMS 7.1.0
    • contains security bugfixes only
  • 7.2.0
    • minor release containing results of recent release sprint, focused on prioritized topics
  • ... time and release sprints pass by ...
  • 7.17.0
    • release candidate for TYPO3 CMS 7
  • 7.18.0
    • final release for TYPO3 CMS 7
    • maintenance phase for TYPO3 CMS 7 starts
    • will be branched of and tagged
  • 7.18.1
    • patch level release
    • contains bugfixes
  • 7.18.2
    • security release based on TYPO3 CMS 7.18.1
    • contains security bugfixes only


  • "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

Expected benefits

Benefits for everyone

  • More agile process
  • Fresh code is in production more quickly
  • New features can be adopted earlier by everyone
  • Stable and easy upgrade path with sprint releases
  • Version system gets clearer

Benefits for core development

  • The contributors to the TYPO3 CMS can concentrate on only a couple of features for single snapshot releases
  • less versions need to be maintained for TYPO3 CMS
  • Bigger features are prepared in feature branches

Implementation Details


Kick-Off phase

  • Starts right after a LTS was released (i.e. 6.2 LTS).
  • 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. 7.0.0) - i.e. removing deprecated code.
  • Release is prepared just like the sprint phase described below.

Sprint phase

  • sprint releases are done similar to the linux kernel. After every release:
    • 1) a "merge window" for features opens for a short while.
    • 2) a "feature freeze" is declared, starting a stabilization phase.
    • 3) 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)
    • 4) after stabilization the sprint release is packaged and announced.
    • 5) repeat process from 1)
  • The exact time frames for these periods are not carved in stone, but might get lower as the process gets smoother.

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
  • 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")

Impact on core development workflow


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 7.9.0
  • The method will still be available within TYPO3 CMS 7 LTS
  • The method gets dropped in 8.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 6.2.
  • Was not removed right away in time for 7.0.0.
  • Can be removed in 7.2.0.
  • So it has to be clear to all users, that no deprecated code from previous major versions should be used in production, as they can be removed any time!
  • Code that is marked to be deprecated during the development of TYPO3 CMS 7 will not be removed for that particular version

Deprecated things from 6.2 and earlier can already be removed with the release of 7.0.0 (transition phase)

Breaking changes

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. "6.2" to "7.0.0").

Breaking changes in minor versions (i.e. 7.0 to 7.1) are generally not allowed.


  • 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 CMS Release Team before being included. Especially Security issues might need to use this path.

Documenting Breaking changes, Deprecation and New Features

It's important to note that breaking changes (which include removed deprecations), new features and new deprecations are to be documented explicitly together with the commit that introduces the change. This system will replace the "" file and ease the later creation of release notes, change documentation, "what's new slides" etc.

These documentation should be written as text files in ReST syntax and should be located in typo3/sysext/core/Documentation/ChangeLog/master/ and follow a certain filename convention.

The documents should:

  • For every breaking: document the change, impact and required migration steps.
  • For new features: document the feature and/or provide a link for further information (i.e. to a Blueprint).
  • For new deprecations: document the replacement and the impact of the deprecation.
    • Deprecations should additionally use the phpdoc annotation "@deprecated" in the code, with the format: "@deprecated since X, FILENAME", where "X" is the major version where it was deprecated, and "FILENAME" is the (base)name of the file documenting the deprecation.

Sidenote: The release script in preparation of a new release moves all documentation changes from "master" to a folder named after the release (i.e. "7.0.0"), so it's possible to have the changes grouped and ordered by release.

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).
  • Paths to files in system extensions are not Public API (i.e. location of icons, images, javascript files). If your extension requires such files, copy them to your extension for local use or use available API to load the resource indirectly (i.e. PageRenderer::loadJquery, etc)
  • Signal-Slots and Hooks are Public API.
  • Methods and properties in PHP classes: In an ideal world (i.e. TYPO3 Flow) all methods and properties that are public API would be tagged with "@api". In TYPO3 CMS 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 CMS Release Team.
  • For new classes, it should be made clear from the start what is "@api" and what is "@internal".

Git and Commit messages

Basically the commit message, git workflow and the review system (Gerrit) work as before.

  • Very important: Breaking changes require a "!!!" annotation in the commit message.
  • "Releases:" line should indicate the next major version as "master". In case of a bugfix, it should still address older versions as before (i.e. "Releases: master, 6.2, 6.1, 4.7")
  • There won't be branches for sprint releases (minor releases), they will be released directly from master.

Release Management

  • The TYPO3 CMS Release Team is responsible for the releases.
    • One single person ("release manager") could be defined per release merge freeze and stabilization phase.
    • Release management persons could cycle. Last resort for decisions stands in the TYPO3 CMS Release Team.
  • One dedicated release manager should be declared responsible for the final stabilization prior to the LTS release.

Technical Todos

  • Install tool needs a cli API to call upgrades.
  • Adapt release scripts in order to more easily create "minor version releases" without having to add every version number in XML configuration.



  • How to involve extension authors into this process?
    • Answer: Nothing changes for extension authors, as the versioning schema stays the same. They only need to consider deprecation (as before, but much cleaner).
  • Extensions might might miss the upgrade functionality.
    • Answer: Extensions do not have this functionality today. The "upgrade wizard" functionality from the core could be opened to be used by extensions, but that would also mean also adding an "auto-upgrading of extensions" functionality. Currently not in this scope.
  • Extensions behavior might not be compatible anymore with core snapshots (e.g. from 7.5.0 to 7.6.0) - since database schema might be changed as well.
    • Answer: Not true, since there is backwards compatibility when upgrading from 7.5.0 to 7.6.0. Extension compatible with 7.5.0 will work with all versions from 7.5.0 on until the 7 LTS without any change (depends: 'typo3' => '7.5.0-7.99.99'). To support "8.x" the extension needs to make sure it does not use any stuff that was deprecated in "7.x" and potentially consider the new minimum system requirements.
  • Separate extension versions might need to be maintained.
    • Answer: The extension needs to be maintained in branches like the Core. It is well known that there is no support for branches in TER. The TYPO3 Composer Project aims for a Composer-based Extension Manager replacement in the future that would solve that. In the meantime extensions could use Composer as a way of dealing with "6.2" and "7.x" compatibility, as Composer support is present in both versions already.

Agencies workflow

  • Current deployment tools might need to be reimplemented (albeit the new solution is more promising since the Core takes care of upgrading and downgrading then)
    • Answer: Only relevant for users of sprint releases, which need to adapt their strategy anyway.


  • How can we make sure the old supported branches (4.5 and 6.2) are not forgotten?
    • Answer: nothing changes here, we still use the same mechanism of identifying them (using the "Releases:" line in commit messages).
    • In the long run, a maximum of three major versions will need to be supported at the same time. In the transition phase we still support five versions (7, 6.2, 6.1, 4.7 and 4.5) or four versions (when 6.1 is EOL).


Stabilization phase might be too short for a "very big new feature" (like FAL or Package Management in the past), maybe some other strategy needs to apply for these.

  • Bigger features will be prepared more and more on forks (i.e. on Github) or separate branches (on
  • Undefined yet how we should use Gerrit to handle the workflow of merging and reviewing bigger features.
  • This problem is not related to this Blueprint but is of a general nature that we had also before the release cycles change and needs to be adressed separately.

External links for clarification of technologies

Further links to improve details of the process