Skip to content

[RFC] PHP Language Level for Symfony 6 #40389

Closed
@derrabus

Description

@derrabus

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.

Overview

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:

  • JSON_THROW_ON_ERROR
  • 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.

Conclusion

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    RFCRFC = Request For Comments (proposals about features that you want to be discussed)

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions