Road to 6.2: a hot feature freeze phase

We are now in the first week of the so called "Feature Freeze" phase on the development of the next release of TYPO3 6.2. What is going on and where are we heading?
Added by Ernesto Baschny about 3 years ago

Since the release of beta1, the 6.2 development entered a phase called "feature freeze". This means that we stop adding new features at will and only do that for very special circumstances and always in agreement with the release manager.

The focus is now on:

  • fixing bugs in our new features
  • stabilize new APIs
  • increase performance
  • enhance the core's "best practice" character (i.e. by correctly using our own API)
  • improvements and fixes in the backend styling

Features after feature freeze?

Yes, it is not uncommon that "last features" still enter after beta1, but these have to be clearly agreed upon with the release manager and be in line with the already proposed goals for 6.2.

What makes this release special is the LTS character. We know that this is a release that will be the most used for the next three years. We learned that from the 4.5 release. This doesn't mean that we just stuff in as much as we can, we still need to consider every addition with care.

So here is the current state of exceptions for feature freeze and their explanation, which are targeted for "beta2", to be released on November, 12th:

File Abstraction Layer

The FAL gained essential features last minutes before feature freeze in splitting up sys_file and sys_file_metadata and allowing the latter to be localized. Despite fixing bugs and improving performance, we want to finish up the work required for a migration from DAM, mainly these two topics:

  • Indexing refactoring, also providing a Extractor Interface (#52841, also outlined in this blueprint)
  • Introduce Signals in IndexRecordRepository and MetaDataRepository: (#52952)
  • 'placeholder' feature in TCEforms should recurse into relations (#52630). This is why you currently see "0" as a placeholder in file relations in beta1. We need this recursion feature!

Categorization API

We already make much better use of the categorization API introduced with TYPO3 6.0. Pages and Content Elements can be categorized by default, categories can be sorted in the backend and we allow multiple category fields per table.

To make the categorization system usable for integrators we've added a categories based menu (#51161). To really complete the usage of system categories in the Core in the frontend, there is already a very mature feature not merged to the core yet, but which might be included in beta2:

  • Provide a menu of categorized content elements (#52137)

Logging API

The goal setup in the kickoff for 6.2 was to make the core use the logging API introduced in 6.0. Unfortunately this goal was not achieved yet due to it's complexity.

  • Deprecate devLog (#52694). This is just a tiny part of the big plan, but nevertheless an important one. Due to conceptual questions which popped up during implementation and review phase, we agreed to allow this change to be merged only if it is based on an approved concept beforehand (in form of a Blueprint).
  • Graylog Logger won't be part of 6.2: Steffen Müller is not able to finish up a "solid" work during the next time, so he decided to ship this work as an extension in TER.


  • Wizard to add OpenID to backend user (#49310). This was part of an ongoing process of fixing OpenID login problems and was already merged (and will be part of beta2).


The rsaauth extension will be used more intensively because "saltedpasswords" is now the new default authentication method for the backend. This extension has some conceptual drawbacks which doesn't allow us to fix easily some very annoying bugs.

  • Nicole Cordes (who gained lots of rsaauth expertise while working on our saltedpasswords tasks) will work on some refactoring of this extension to provide a more universal API, allowing us to fix issues like #34568 and making it more useful for other extensions (i.e. a javascript method to register any forms and fields requiring "encryption" - not only our login forms).

Package Management

This conceptually intrusive feature added in beta1 will still need some love and care and maybe one or two additional API changes.

One already known required feature:

  • Allow the activation of packages during runtime (#53015) - this is required for scenarios where the static "PackageStates" is not enough and you require a different set of activated packages in development and production systems (formerly one could add extensions to the "extList" by AdditionalConfiguration.php which is not possible with the new Packagemanagement yet).

Usability Improvements

The UX team with Jens, Lars and Martin worked on identifying lots of "buggy" styling issues in the 6.2 backend (and Install Tool). We will target the most prominent issues as good as we can to be able to at the end provide a consistent and solid backend for our users.

The goal currently is not to completely change the backend look and feel, but to either finish up open and doable tasks or revert certain unfinished areas.

Speed Speed Speed

During the last code sprint before feature freeze and still being debated in the team is the need to regain performance in TYPO3. We are aware that since 4.5 a lot of refactoring made the code cleaner and more robust, but in certain scenarios the performance got worse from release to release. Due to the fact that releases between the LTS releases (4.6, 4.7, 6.0, 6.1) were not used so much by major installations, this performance degradation hasn't come to the attention, and most will be hit by it first time when upgrading from 4.5 to 6.2.

To minimize the impact the CMS team is currently working hard (i.e. in #52949) to identify and potentially solve the most important performance issues.

Benchmarking is a difficult topic, and we currently have no standardized way of benchmarking TYPO3 Core to identify exact commits which affected the performance. The difficulty lies in setting up correct installations and creating useful scenarios which can provide useful information at the end. The art lies in being able to interprete the statistics generated by benchmarking tools and it's impact.

The idea of hosting a "Performance Code Sprint" popped up. It could be something to be planned for November.

But in general we invite every performance interested TYPO3 developer or integrator to help us with profiling, identifying bottlenecks, and working on solutions - instead of simply complaining about it. Let's look into the future and not in the past.

Help us make 6.2 rock!

We invite every user, developer, integrator, web agency and interested party to help us make 6.2 the best release ever. Report bugs, share your performance findings, discuss solutions with the team (i.e. through the mailing list / forum typo3.teams.core or the core issue tracker): participate! It's not a CMS from the "Core Team", it's a work from the whole TYPO3 community!

We already have lots of very nice features included, and it's up to the help of you to make it also a very stable product, something which the TYPO3 CMS has a long reputation of being.


Added by Jan Kornblum about 3 years ago

How about adding a new category "Category" (like "FAL") to the bugtracker "new issue" window, to be able to assign all sys_category related issues to it?

Added by Michael Stucki about 3 years ago

Hi Jan,

thanks for your suggestion. I have added the category now.

Greetings, Michael