Description
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
andthrow
expressions - Internal functions throw
TypeError
s andValueError
s 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?