[RFC] PHP Language Level for Symfony 6 #40389
Comments
|
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. So, 8.0 for me. |
|
I agree with bumping to 8.0 👍🏻 |
|
+1 for php 8 |
|
can we reasonably predict min php version for future versions? to be displayed at eg. https://symfony.com/releases/9.4 |
|
@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 🎉 |
|
I would also like to vote for PHP 8! 🙂 |
|
👍 for PHP 8. |
|
👍 from me for PHP 8 as well |
|
My vote may not mean too much, but 👍 from for PHP8. |
|
+1 for PHP 8.0. Will make things so much better and it's not hard to go from 7.3 or 7.4 to 8.0! |
|
👍 PHP 8.0 👍 |
|
PHP 8.0 as the minimum version supported 🙏🏻 |
|
PHP 8.0 👍🎉 |
|
PHP 8.0 👌🏼👍🏼👍🏼👍🏼🙂 |
|
thumbs up for PHP 8.0 !! |
|
PHP 8.1, that seems a bit bold but I do think the main obstacle against PHP version upgrades are BC breaks. If one can be on PHP 8, they very well can be on PHP 8.1 PHP 8.1 gives a lot of features over PHP 8, most notably Enums 🎉, restricted $GLOBALS usage (which I believe needs some hacks in symfony code base at the moment), array unpacking with string keys and I believe there is more to come. |
|
👍 for PHP8 |
|
🔔 PHP 8 👌 |
|
Another one for PHP 8 |
|
I'd vote for PHP8 🎉 |
|
+1 for PHP 8.0 |
|
All right. Wow. I did not expect the outcome of this RFC to be that crystal clear. 🤩 |
|
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) |
|
maybe i will not add anything new to topic, but +1 for php8. |
|
PHP 8 would help with documentation, as we could exclusively show attributes instead of annotations :). |
|
PHP 8.0 |
|
I would suggest going for 8.0 . By the time Symfony get released it will be already several bug fixes in, therefore not "dangerous" bleeding edge. |
Yes, or at least default to attributes. Unfortunately, there's still a gap to fill: #38503 |
|
Let’s close now, 8.0 is the winner here. |
|
Not php 8, just to jave different options. |
|
PHP 8 |
|
There is no way it could not be PHP 8 - PHP 7.4 will end its active support the very same month Symfony 6 would be released. Symfony 6 has to be on PHP 8. |
|
Follow up in #40420 FYI. |
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:
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
PHP 7.3 was mainly a maintenance release. By bumping we would gain:
JSON_THROW_ON_ERRORPHP 7.4
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:
__serialize,__unserializeall the way)??=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
We would gain:
mixedtype,staticreturn typematchandthrowexpressionsTypeErrors andValueErrors which allows us to remove some hacks with custom error handlers.psr/cachev3Again, 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
We would gain:
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?
The text was updated successfully, but these errors were encountered: