In the past, the most common argument against bumping the PHP version was that some major Linux versions were using an older version. This time, as you said, at least Ubuntu LTS is aligning perfectly with our needs, so hopefully other major Linux distributions do the same. 👍

According to:

• https://packagist.org/packages/symfony/console/php-stats#6
• https://packagist.org/packages/symfony/http-foundation/php-stats#6

~50% at the time of writing, is already running php v8.1 :)

Also, looking at https://packagist.org/packages/symfony/framework-bundle/php-stats#6.0, early adopters of Symfony 6 are already using PHP 8.1 en masse, and it's growing fast.

This is only because Laravel 9 only was released only yesterday. Lots of those users will be on PHP 8.0.

Not sure if this will affect your decision or not but AWS EB doesn't yet support PHP 8.1. I think most of the other PAAS providers offer PHP 8.1 though (except Google AppEngine which afaict doesn't even offer 8.0 support yet).

ldap_rename(): Passing null to parameter #4 ($new_parent) of type string is deprecated

This shoud be fixed on lower branches. PR welcome anyone, that's a good first contrib :) Fixed in 9ce4531

TypeError: Memcached::setMulti(): Argument #2 ($expiration) must be of type int, int given

🤦

Anyway, this PR is ready to go from a technical pov, remaining failures are false positives.

Not sure if this will affect your decision or not but AWS EB doesn't yet support PHP 8.1

Thanks for the info @jenkoian. That shouldn't be a blocker to me.

The Packagist statistics seem to be in your favor:

• Among the consumers of FrameworkBundle 6.0, PHP 8.1 is already the dominant PHP branch. https://packagist.org/packages/symfony/framework-bundle/php-stats#6.0
• If we look at the 4.4 branch, our LTS that is approaching EOL, we see that we maintain support for a PHP version 7.1 that is almost irrelevant for the consumers of that package. https://packagist.org/packages/symfony/framework-bundle/php-stats#4.4
• On 5.4, it's a similar story. We support PHP 7.2 and 7.3 for a very small fraction of our userbase: https://packagist.org/packages/symfony/framework-bundle/php-stats#5.4

However, this is a major change in our release strategy: we haven't bumped the PHP language level in a minor release yet. If we take that road, I believe we should announce this a bit ahead of time. The fixed release cycles of PHP and Symfony should encourage development teams to schedule their framework and infrstructure upgrades ahead of time. Projects that chose to start with or upgrade to Symfony 6 might have done so trusting that they can remain on PHP 8.0 for a certain period of time. If we bump now, we basically force those projects to either reschedule infrastructure upgrades or to remain on Symfony 6.0 beyond its EOL.

If we would've discussed and announced that course of action before the 6.0 release, I would be all cool with it. But bumping to PHP 8.1 on such a short notice might make Symfony's release strategy appear erradic.

How would you feel about postponing this language level bump to the 6.2 release? That could give downstream projects a bit more time to adjust their development schedule accordingly.

For us that means that we need to delay our Symfony update to 6.0, since its maintenance is that limited and we'd be locked with an unmaintained version until we get 8.1 support done.
Get the motivation though, only sharing the impact for us.

Same for us. We usually skip the *.0 release of a new major, to have 6 months to fix the deprecations introduced in 5.4. So our infrastructure (PHP 8.0 at the moment) is not reflected in the Packagist statistics for 6.0.

This is a deviation from the standard release schedule. We usually do not "push" the industry to upgrade their infrastructure, but instead consider our minimum PHP version when the current one has reached eol (or is about to), giving the largest amount of time for everyone to upgrade a single thing at the time.

I think it comes down to weighing this deviation with postponing typed properties for another 6 months.

I do love to remove code and I also appreciate using the latest version of PHP.

This goes against what Symfony has done in the past (for better or for worse). I would suggest to be boring and keep 8.0 compatibility. At least for SF6.1. Im more open to drop PHP 8.0 it in SF6.2 if we still think we have a strong case for it.

Just briefly from Drupal's standpoint:

We're planning to release Drupal 10 on Symfony 6 this year. We've set our minimum requirement at PHP 8.0.2 because that's the current minimum of Symfony 6.0, however we're already recommending PHP 8.1.

We have active discussions happening about requiring PHP 8.1 or not (https://www.drupal.org/project/drupal/issues/3223435 / https://www.drupal.org/project/drupal/issues/3173787). And we've notified people that we'll announce an 8.1 bump at least five months in advance: https://www.drupal.org/about/core/blog/drupal-10-php-requirements-announcements

There are several reasons we'd like to require PHP 8.1, but we're also balancing it against distro/hosting availability (which is somewhere between promising and mixed). Obviously this issue was just opened in the past 24 hours so that's new information for us that hasn't fed into the current discussions yet.

If Symfony definitely goes ahead with this, it would be good to know as soon as possible. Based on the state of the discussions we're having, I don't think it's likely we'd try to stop you, but we also haven't definitely decided to require PHP 8.1 ourselves independently yet.

It's important to acknowledge the reason why I'm proposing this. We do have a strong case here, and it's not going to go away. PHP 8.0+preloading+typed props is broken, see linked issue.

I'm personally fine postponing to 6.2 if that's useful for the ecosystem. We'll need to reverse once more the types added to private properties before tagging 6.1.

On the other hand, we are months ahead the release of 6.1. We're not rushing anything here.

Talking with others from the core-team on Slack, it looks like we have two ways forward:

• postpone this to 6.2 and revert typed properties from 6.1. There's an issue with this approach: ppl on PHP8.0+SF6.1 will remain with an unmaintained version of SF once 6.1 is EOL. Considering security issues, that's not great. Hoping that nobody will end up in this situation is a wild dream I fear. To fix this trap, we might need to extend the security maintenance of 6.2 by 8 months to overlap with 6.3.
• which leads to this alternative: do this in 6.1, and extend the security maintenance of 6.0 to the EOL of 6.1.

My preference is for the latter: it allows sending the message sooner and provides a smooth way forward while saving maintainers' time.

So this was resolved/decided on the Drupal side sooner than here.

@mxr576 , Drupal's decision is not unrelated to this PR. ;) Also, the Drupal community had already been agonizing over the decision of PHP 8.0 vs. 8.1 for 6 months, and we were fortunate enough to be in the development phase of a new major. I think we can all be patient for a couple weeks here. :)

@xjm my previous comment was just an FYI for ppl involved in this decision here. It was not positive or negative. I am sorry if someone can felt otherwise.

(Personally, I can fully support that decision , it is a future proof one.)

In case you missed it, we're going to merge this PR.
See https://symfony.com/blog/symfony-6-1-will-require-php-8-1

PR is ready, failures are:

• a false-positive on GHA
• a legit failure on appveyor, but the fix should land on branch 4.4 (I'm going to have a look).

Thank you @nicolas-grekas.