[RFC] PHP Language Level for Symfony 6

Symfony 6 will be released this year in November and traditionally, we bump the minimum required PHP version with such a major release. This helps us to continuously modernize the codebase and to remove compatibility code for PHP releases that are not maintained (and thus shouldn’t be used) anymore.

I’d like to discuss the options that we have, so we can come to a good and well-informed decision.


The following PHP requirements have been set in the past for Symfony major releases:

Symfony major maintenance period min. PHP version maintenance period
2.0 – 2.8 07/2011 – 09/2019 5.3 06/2009 – 08/2014
3.0 – 3.4 11/2015 – 11/2021 5.5 06/2013 – 07/2016
4.0 – 4.4 11/2017 – 11/2023 7.1 12/2016 – 12/2019
5.0 – 5.4 11/2019 – 11/2025 7.2 11/2017 – 11/2020
6.0 – 6.4 11/2021 – 11/2027 TBD TBD

The options

Given that we want to continue the tradition and bump PHP at least by one minor version, we have the following options.

PHP 7.3

  • Initially released December 2018
  • Receives security fixes only and will EOL shortly after the Symfony 6 release.

PHP 7.3 was mainly a maintenance release. By bumping we would gain:

  • Indented heredoc and nowdoc statements
  • Trailing commas in function calls

PHP 7.4

  • Initially released November 2019
  • Actively maintained at the moment and will enter the security support phase at the same time as Symfony 6 is released
  • The final PHP 7 minor release

PHP 7.4 was a big step forwards. It introduced features that I actively use in my projects and I would be delighted to see them in Symfony’s codebase as well.

We would gain:

  • Arrow functions
  • Typed properties
  • Covariant return types and contravariant parameter types
  • We can assume preloading to be available (though not necessarily enabled)
  • We can simplify serializable classes (__serialize, __unserialize all the way)
  • Oh, and most importantly, we could use the ??= operator as several Psalm users have already told us. 😉

If we plan to update the codebase with return types, the introduced covariance is certainly a feature that we want to have. PHP 7.4 is currently bundled by the stable and LTS releases of Debian and Ubuntu. In Packagist’s November 2020 report, it had an adoption of 42.6%% and I would assume that this number has grown since then. Given that the upgrade to PHP 8.0 has been bumpy for the projects I’ve seen, I would also assume that PHP 7.4 will live a little bit longer that usual.

PHP 8.0

  • Initially released November 2020
  • Actively maintained until November 2022, EOL in November 2023.

We would gain:

  • Union types, mixed type, static return type
  • Attributes could be a first-class citizen in Symfony
  • Constructor property promotion
  • The nullsafe operator, match and throw expressions
  • Internal functions throw TypeErrors and ValueErrors which allows us to remove some hacks with custom error handlers.
  • We could implement psr/cache v3

Again, if we plan to introduce return type declarations, we would probably need to leave some holes when doing so on PHP 7.4 that we would be able to fill in PHP 8. The whole type system feels a lot more complete here.

PHP 8.1

  • Will be release at the same time as Symfony 6
  • The feature set is still WIP

We would gain:

  • Enums?
  • Constructor calls in initializers? Nested atttibutes?

This would be a bold move. Too bold, probably.


I think the only two options that would really make sense are 7.4 and 8.0. With 7.3, we wouldn’t gain much. Applications are already migrating away from it and I expect that release to become pretty much irrelevant soon. By requiring 8.1, we would slow down Symfony 6’s adoption too much, cutting off too many developers from the active feature development.

PHP 7.4 would certainly be the save bet. It’s a feature-rich release, included in popular Linux distributions already. However, PHP 8.0 would overall be the larger step forward for Symfony.

What do you think?

9 thoughts on “[RFC] PHP Language Level for Symfony 6

  1. Thank you @derrabus for giving us all the information to make the decision much easier to make.

    I think we need to set the minimum version to 8.0.
    Supporting 7.4 does not make sense IMHO as 5.4 (which has the same features as 6.0 is a LTS) and will reach OEM right after our release.

    So, 8.0 for me.

  2. @derrabus thanks for this detailed summary. I’m extremely happy to read that Fabien and others vote for PHP 8. It’s the best PHP version in years. Using it would have a very significant impact in Symfony project.

    So, another vote for PHP 8 🎉

  3. I agree with both @derrabus and @fabpot: people who can’t upgrade to 8.0 can use Symfony 5.4 on PHP 7, but the improvements in PHP 8 allow us to be braver when introducing new features in subsequent versions.

  4. Having a minimal requirement to php 8.0 does not mean that you can’t use PHP 8.1, and it neither means we won’t provide features dedicated to php 8.1+. We already provide Attributes in Symfony 5.x while the minimal requirement is 7.2.

    Having a minimal requirement to php 8.0 does not mean we will switch everything to the new hype features, For the same reason we didn’t switched to short array syntax with php 5.4: merging bugfix from 5.x to 6.x could be very complex when everything had changed upstream.

    End-users would only be affected by cleaner interfaces (union type, enum), everything else only affect people that contribute to symfony’s code.

    As a user, I don’t really care about the minimal version.

    As a maintainer, I’d vote for php 8.0 and adds an other reason to the list, it would ease integration with our vendors that are less flexible than us, and thus will reduce the complexity in our bridges.

    Don’t forget we are choosing a version that will be supported until 2026 (which mean +6 PHP version from)