Releasing Neos and Flow

This page provides an overview of how we approach releases. Neos and Flow have the same release lifecycle and release process.
For users of Neos it explains what to expect in a release and when when release is done.
For release managers it helps to understand their role in this process.

Release Roadmap

We strive for a regular Neos release every four months. The team will focus on key features for each release that will be prioritized from user feedback and actual project needs.


Starting with 7.0 the versions of Neos and Flow are in sync. For that reason there is no Neos 6.0

Past releases

There is a number of outdated releases that are no longer supported:

Neos 1.2, 
Flow 2.3

Dec 2014
Officially supported until  
Apr 2016
Security updates until 
Apr 2017

Neos 2.2,
Flow 3.2

Apr 2016
Officially supported until 
Apr 2017
Security updates until 
Apr 2018

(we had different support ranges for Neos 2.0 and 2.1) 

Neos 2.3 LTS,
Flow 3.3 LTS

Aug 2016
Officially supported until 
Aug 2018
Security updates until 
Aug 2019

(we changed our support scheme with the release of 2.3, so that upcoming versions are equally long supported as the past LTS)

Neos 3.0-3.3,
Flow 4.0-4.3

between Dec 2016 and August 2017
Officially supported until
Aug 2018
Security updates until
Aug 2019

(same support ranges as Neos 2.3 LTS / Flow 3.3 LTS)

Neos 3.3 LTS - Neos 4.2,
Flow 4.3 LTS - Flow 5.2

Dec 2017
Officially supported until  
Dec 2019
Security updates until
Dec 2020

What's in a Release?

While this may be an interesting question to some, it isn't to us. In some cases we might plan a certain feature to be done for a specific release, but in general we just work on features and merge them into the master branch when they are done.

From this branch the next minor release is done as scheduled. So whenever a feature is merged in master, it is known when it will be released.

Breaking changes are usually held back (maybe in a separate branch or even a developer's fork) until it is known the next release done off of master will be a major release. Another option is the use of a branch to officially collect changes for the next major release earlier.

Semantic Versioning

Neos releases follow Semantic Versioning, meaning in a nutshell that given a version number MAJOR.MINOR.PATCH, increments to the:

  • MAJOR version indicate incompatible changes to the public API,
  • MINOR version indicate added functionality in a backwards-compatible manner, and
  • PATCH version indicate backwards-compatible bug fixes.

See for the full details on this.

It is notable that a major release is not always defined by great new features. Features are introduced in minor releases as well. But a major release will come with breaking changes (and usually some new features made possible by them).

Definition of Incompatible Changes

For semantic versioning to work, one needs to know what the public API of a system is. The public API of Neos and Flow is made up of the following components:

  • PHP API as documented
  • Validator settingsViewHelpersFusion objectsEel helpersFlowQuery operations
  • Configuration provided by our packages (YAML files in the various packages)
    • Settings: no removals / renames are allowed!
    • Caches: adding caches / changing defaults must be documented!
    • Policy: the syntax, predefined roles
    • Objects: syntax (possible changes limited by public API)
    • Routes: syntax (in general there should be few interaction with third-party packages)
    • NodeTypes: predefined node types
  • Database schema: migrations that do irreversibly change data or lead to downtime
  • Public default output (e.g. Neos markup in frontend, like the CSS classes)
  • Minimum requirements (PHP or Browser versions)

Note: For JavaScript we have no fully defined public API yet, except the documented editors/validators.

Every change to the above which requires an action by the user, integrator or developer which can't be easily executed as an automated task during deployment is a breaking change and requires a major version to be released.

According to that definition, code migrations are breaking, but database schema upgrades or node migrations (if they can really be executed safely during a deployment) are okay.

Even the cases were the needed adjustments can be automated will be clearly documented so the user can assess the impact of such a change.

When following Semantic Versioning, there is no point in releasing one major version after another. That means we need to take an extra look on changes which break backwards-compatibility. A release schedule helps to plan ahead - if we know when the next major version is being scheduled, we can either postpone backwards incompatible changes to a later version or maybe find a creative way to make the change compatible.

  • Three minor releases per year, with patch level releases as needed in between
  • Major releases happen yearly, assuming there will be breaking changes
  • Each release receives bug fixes for at least 1 year (extended by previous LTS) and security fixes for 1 additional year (at least 2 in total)
  • Each Long Term Support (LTS) version receives bug fixes for 2 years and security fixes for 1 additional year (3 in total)

This results in a simple and predictable scheme. In the (unlikely) event of no breaking changes being present, no major version is released, minor versions are released instead. In such a case a minor release will be declared as LTS, making sure the flow of LTS releases stays intact.

The Release Cycle

A Release Manager is responsible for a release branch that includes a specific new release and all of its bugfix releases (i.e. The Release Manager for 2.0 is responsible for 2.0.1, but not 2.1). The Release Manager is responsible, throughout the maintenance lifetime of their specific release branch, for the following things:

  • Schedule and coordinate contributions for a specific release branch and all of its bugfix releases.
  • Prevent feature creep within the release branch by having a vision of what features can or should be included in the release.
    • The release manager has the final say on which changes can be included in the release.
  • Make sure that any major features are included in release notes before the feature is merged into the release.
  • Collaborate with the community contact and public relations manager to:
    • communicate the timeline and release branch vision,
    • write and distribute release announcements, and
    • other release specific communication.
  • Be available to answer questions about whether or not to include a change in the release branch.
  • Make sure releases happen, including the release branch's new release and all bugfix releases.

Release Managers


  • Neos 7.0 release manager:
    Bastian Waidelich, Markus Günther & Jon Uhlmann, Team Tiga
  • Neos 5.3 release manager:
    Karsten Dambekalns, Robert Lemke & Dmitri Pisarev, Team Minions
  • Neos 5.2 release manager:
    Alexander Berl & Christian Müller, Team Unicorn
  • Neos 5.1 release manager:
    David Spiola, Team Tiga
  • Neos 5.0 release manager:
    Daniel Lienert & Karsten Dambekalns, Team Minions
  • Neos 4.3 release manager:
    Gerhard Boden & Martin Ficzel, Team Unicorn


  • Flow 7.0 release manager:
    Bastian Waidelich, Markus Günther & Jon Uhlmann, Team Tiga
  • Flow 6.3 release manager:
    Karsten Dambekalns, Robert Lemke & Dmitri Pisarev, Team Minions
  • Flow 6.2 release manager:
    Alexander Berl & Christian Müller, Team Unicorn
  • Flow 6.1 release manager:
    David Spiola, Team Tiga
  • Flow 6.0 release manager:
    Daniel Lienert & Karsten Dambekalns, Team Minions
  • Flow 5.3 release manager:
    Gerhard Boden & Martin Ficzel, Team Unicorn

Older versions not maintained any more (except for security fixes as shown in the release timeline):

Neos 4.x

  • Neos 4.2 release manager:
    Jon Uhlmann, Team Tiga
  • Neos 4.1 release manager:
    Karsten Dambekalns & Daniel Lienert
  • Neos 4.0 release manager:
    Christian Müller & Markus Goldbeck

Neos 2.x

  • Neos 2.3 release manager:
    Dominique Feyer & Christian Müller
  • Neos 2.2 release manager:
    Karsten Dambekalns
  • Neos 2.1 was coordinated by:
    the Minions team
  • Neos 2.0 release managers:
    Aske Ertmann & Christian Müller

Neos 3.x

  • Neos 3.3 release manager:
    Martin Ficzel & Wilhelm Behncke
  • Neos 3.2 release manager:
    Gerhard Boden & Sreyleak Helzle
  • Neos 3.1 release manager:
    Alexander Berl, Bernhard Schmitt & Karsten Dambekalns
  • Neos 3.0 release manager:
    Robert Lemke & Johannes Steu

Neos 1.x

  • Neos 1.2 release manager:
    Aske Ertmann
  • Neos 1.1 release manager:
    Christian Müller
  • Neos 1.0 release manager:
    Sebastian Kurfürst


  • Flow 5.2 release manager:
    Jon Uhlmann, Team Tiga
  • Flow 5.1 release manager:
    Bernhard Schmitt, Daniel Lienert & Karsten Dambekalns
  • Flow 5.0 release manager:
    Christian Müller
  • Flow 4.3 release manager:
    Martin Ficzel & Wilhelm Behncke
  • Flow 4.2 release manager:
    Gerhard Boden & Sreyleak Helzle
  • Flow 4.1 release manager:
    Alexander Berl & Bernhard Schmitt, Karsten Dambekalns
  • Flow 4.0 release manager:
    Robert Lemke & Johannes Steu
  • Flow 3.0 release manager:
    Bastian Waidelich

Breaking the Rules

This policy will be followed on a best-effort basis. In extreme cases it may not be possible to support a release for the planned lifetime; for example if a serious bug is found that cannot be resolved in a given major version without significant risk to the stability of the code or loss of compatibility. In such cases, early retirement of a version may be required.