[policy] Require PHP 8.1 for Drupal 10.0 if a dependency does, otherwise require PHP 8.0. (up from 7.3 in Drupal 9)

Linked issue to #3118147: [meta] Set Drupal 10 platform and browser requirements six months before the release

Updated issue summary heavily.

The disadvantages of requiring a new major includes dropping deprecated features which inevitable will cause some headaches. For example, removed ability to call non-static methods statically, is_callable will fail when checking for a non-static method with a classname (must check with an object instance). There's also display_startup_errors is now enabled by default. Non-absolute trait method references in trait alias adaptations are now required to be unambiguous. And so on. All in all, a major version change is no small thing.

I'd like to table an alternative: release Drupal 10 with PHP 7.4 support and announce a year ahead Drupal 10.1 requiring PHP 8.1. Let's eat the Drupal trouble with Drupal 10.0 and let's eat the PHP trouble with Drupal 10.1. The gap between PHP 7.4 EOL and D10.1 release is very small. And by the time Drupal 10.1 releases, PHP 8.0 leaves active support so uptake for 8.1 should be really good.

@Charlie ChX Negyesi
The idea of releasing a new major Drupal version is about dropping deprecated features? Do you think that if PHP 7 support is dropped by Drupal 10, the list of what is getting deprecated now, gets too long? Or would the things you mention cause major issues when a module tries to support Drupal 9 and 10 at the same time? If so, would that mean that modules that are supporting Drupal 9 right now, are incompatible with PHP 8?

The idea of releasing a new major Drupal version is about dropping deprecated features?

Yes, dropping deprecated Drupal features. It's possible it's easy to drop deprecated PHP features at the same time as well. I do not know. Maybe it's better in one go, maybe not.

Do you think that if PHP 7 support is dropped by Drupal 10, the list of what is getting deprecated now, gets too long?

Yes. I think there'll be some work to get PHP 7 code working properly with PHP 8 and also some other, completely disparate work getting D8/D9 code to work with D10. I feel the two together might be too much. But then again, maybe site owners just want to get the version upgrades done in one and throw it to the wolvesQA department. Maybe there's less QA time if they only need to do a "the whole world might be broken" level of testing only once instead of twice. There's a lot of unknowns here. I know I would prefer doing the two portings separately but that doesn't mean that's what Smartsheet would end up doing even in the hypothetical scenario I suggested -- because of the QA work I mentioned.

Or would the things you mention cause major issues when a module tries to support Drupal 9 and 10 at the same time? If so, would that mean that modules that are supporting Drupal 9 right now, are incompatible with PHP 8?

Yes. Especially custom code might be broken on PHP 8 right now. Just the is_callback and trait inheritance issues I mentioned (and there are literally dozens) are extremely likely to be problematic right now. The trait inheritance is a particularly nasty one as it was a silent acceptance in PHP 7.

Edit: a little bit of context to add. My view of the Drupal/PHP world is extremely biased. A significant part of my job(s) is/are solving bugs others don't want / can. I constantly see the worst behavior of the code. It warps your perception of how bad the problems are. I am always looking for ways code can be broken and find it hard to determine how widespread such brokenness actually is.

There's serious changes in PHP 8.1 already and it's coming this year (alpha starts in a month )

So at the moment of autumn 2022 the 8.0 release will be at security support and 8,2 will out.

Also Symfony already require annotations from 8.0 and not clear what 6.0 minimal requirements will be

There's great write-up of 8.1 release manager https://blog.krakjoe.ninja/2021/05/avoiding-busses.html

I know I would prefer doing the two portings separately

Yes that makes sense but requiring PHP 8 in Drupal 10.0.0 doesn't stop this. You can update to Drupal 9.4, then update to PHP 8, then go from Drupal 9.4 + PHP 8, to Drupal 10 (.0 or .1). This makes every individual jump as small as possible, including for contrib modules which in most cases should be identical between 9.4 and 10.0.

However, what we want to avoid, is people unwittingly installing Drupal 10.0 on PHP 7.4, updating to 10.1 and finding their hosting environment is unsupported, this is the reason that for Drupal 9 we mostly tried to set requirements at the highest reasonable level, as a trade-off for not dropping support within the major cycle.

You can update to Drupal 9.4, then update to PHP 8, then go from PHP 9.4 + PHP 8, to Drupal 10 (.0 or .1).

Yes, that can work, probably that should be another issue: how do we make sure D9.4 and contrib is PHP8 ready? (Consider https://3v4l.org/s5G2I as a terrifying example of super subtle changes. To make it worse, strpos warns for empty needle but stripos doesn't.)

We already have PHP 8 testing environments: https://www.drupal.org/node/3060/qa.

catch, thanks for the support. This is looking much better than I thought.

So there's something very interesting on that page:

9.3.x-dev defaults to PHP 8 and tests PHP 7 on commit while 9.2.x-dev defaults to PHP 7 and only on commit tests with PHP 8.

What do you think of

1. a change notice urging contrib authors to set up something similar? The last change notice I can find mentioning PHP 8 is not a particularly positive one: https://www.drupal.org/node/3180764
2. adding a warning but not an error to the status report of 9.3 that PHP 7 is near dead? PHP 7.4 gets active support until 28 Nov 2021 where Drupal 9.3 is targeted for December 8, 2021 so it's really the truth.

Upgrade Status already tells you to update to PHP 8 on your Drupal 9 environment. See #3202955: Start checking PHP 8 requirement on Drupal 9:

I've opened #3214920: Increase DRUPAL_RECOMMENDED_PHP to 7.4 to start recommending PHP 7.4 as the minimum in 9.2, and #3214924: Increase DRUPAL_RECOMMENDED_PHP to 8.0 in Drupal 9.3 or 9.4 to start recommended PHP 8 in either 9.3 or 9.4. We already have this all set up, it's just changing a constant.

Fantastic, thanks! What about the change notice I recommended?

@Charlie ChX Negyesi that's more up to the DA - we could open issues to request that the default environment be changed to 7.4 (then 8.0 in six months). Encouraging contrib to set up multiple environments for testing means double the test runs, which is double the server costs.

Symfony 6 requires PHP 8: https://github.com/symfony/symfony/pull/41282

As per https://github.com/symfony/symfony/issues/40389, Symfony 6 will not require higher than PHP 8.0, so at least we don't need to require it either for Symfony. Do we know of any other dependencies that would force our hands? PHPUnit has been a lot more conservative recently with PHP version support, so I expect we can be on PHP 8.0 as a requirement without needing to increase that further for PHPUnit.

Looking at links it's not clear, looks phpunit 10 will set dates for both 8 and 9

https://phpunit.de/supported-versions.html

https://phpunit.de/announcements/phpunit-9.html

Do we know of any other dependencies that would force our hands?

In general what seems to happen is that most of the projects we rely on stick to Symfony minimum dependencies around when there's a new major Symfony release, but then drift upwards after that. So phpunit requiring 8.1 by the middle of next year might not happen, but it could well at the end of 2022 or mid-2023 or similar.

This doesn't give us loads of options, since it may still be to early to require PHP 8.1 in June 2022 (maybe not if we end up with an August or December release date though), and even if we do, we might still have to deal with dependencies requiring PHP 8.2 - especially if we release on Symfony 6 and therefore have a longer security support cycle.

Opened #3223435: Track PHP 8.1 support in hosting and distributions for gathering data to inform discussing when/if to require PHP 8.1 based on suggestion from @xjm.

If we do #3238652: [policy] Decide how long major Drupal versions should be supported, then I'm +1 to setting Drupal 10's PHP minimum to 8.0, not 8.1. Adding the ".0" to the issue title for clarity, so it's clear what the "Needs review" status is for.

In terms of what we'll lose out on for Drupal 10 with respect to not being able to use PHP 8.1 language features:

• I think we'll still be able to refactor our plugin annotations to attributes, even without support for nested attributes. I'll open a separate issue detailing that.
• I think we'll still be able to make progress on #2218651: [meta] Make Drupal compatible with persistent app servers like ReactPHP, PHP-PM, PHPFastCGI, FrankenPHP, Swoole, even without core calling the Fiber API directly, and instead leaving the responsibility of fiber management to ReactPHP and friends, and Drupal contrib services if necessary.
• We can add AVIF support in contrib, or an optional core module that requires PHP 8.1.
• For all the other language niceties, like first class callables and intersection types, we can wait 2 more years for Drupal 11.

Any disagreements with the above?

Two things to add to #22:

First, with PHP 7 to 8 and Symfony 5.4, we've accumulated a lot of Drupal 10 only Symfony 5.4 compatibility fixes - see the Drupal 10 section of #3161889: [META] Symfony 6 compatibility. This is not a huge problem, we're nearly ready to open the Drupal 10 branch, and it doesn't hurt us waiting too much.

Assuming Symfony 7 requires PHP 8.1 or 8.2, we'll end up with a set of Drupal 11-only changes for Symfony 6.3/6.4 deprecations that rely on dropping PHP 8.0 support. We've been able to resolve every other Symfony 5.4 deprecation in Drupal 9 in a bc-compatible way so far.

If we finally go ahead with #3020303: Consider using Symfony flex to allow switching between major Symfony versions, then that could be a small barrier to doing so.

However, this is at worst a minor inconvenience for core development and bleeding edge contrib development, so I don't think it outweighs anything else.

Secondly, and potentially more seriously: if any of our non-Symfony dependencies add a new major release requiring PHP 8.1 between now and June 2022, then we'll be stuck on their previous major version for the entire Drupal 10 cycle, which would not be good. We've already run into similar issues with phpunit (although phpunit has widened their PHP version support so it's got less bad than it was). We've also been left behind by Guzzle in Drupal 9 and now having to shim Guzzle 6 for PHP 8 compatibility. (See #3104353: Upgrade to Guzzle 7, #3225966: Consider loosening our constraint to allow sites to install Guzzle 6 or 7, or otherwise handle PHP 8.1 deprecations for Guzzle 6, and #3224421: [PHP 8.1] Add a shim to Guzzle 6 for PHP 8.1 compatibility). This wasn't due to Guzzle 7's PHP version requirement, it's because Guzzle 7.0.0 was released on 27th June 2020, 24 days after Drupal 9.0.0, but Guzzle opted not to include PHP 8.1 compatibility in Guzzle 6 so it's a very close example.

Since PHP 8.1 isn't actually out yet, this hasn't happened yet, but projects may well be discussing it in issue trackers somewhere (or about to do so) the same way we are. If/when one of our dependencies starts to require PHP 8.1, it'd be an overriding reason to go straight to PHP 8.1 - but we might not know for a few months that it's going to happen.

If/when one of our dependencies starts to require PHP 8.1, it'd be an overriding reason to go straight to PHP 8.1 - but we might not know for a few months that it's going to happen

If this happens, how should we handle the fact that Drupal 9 goes EOL in the same month that PHP 8.0 goes EOL? Would we just say to PHP 8.0 users that sorry, unlike in the past, Drupal isn't providing any option to run any supported Drupal version on a PHP version that has only just now become EOL? Or would we consider something like releasing a Drupal 9.5 in November 2023 that's something in between Drupal 9.4 and Drupal 10 (e.g., upgrades Symfony and Guzzle, removes CKEditor4, and brings in whatever other changes were made in 10 that are needed to be able to support it for 2024, but that doesn't remove Drupal's own 9.x deprecations that aren't strictly necessary to remove)?

if any of our non-Symfony dependencies add a new major release requiring PHP 8.1 between now and June 2022, then we'll be stuck on their previous major version for the entire Drupal 10 cycle

Is this that much different though than this happening a month or two or six after we release 10.0? If we're willing to accept the risk of it happening in July 2022, why not accept the risk of it happening in February 2022 or November 2021? My concern is that people need to be able to plan for what the requirement will be, so I'd like us to settle on it soon rather than leaving it undecided for a few more months.

@effulgentsia latest news about AVIF are #3202016-34: Let GDToolkit support AVIF image format

as far as getimagesize() goes, tentative good news: some folks at Google who specialize in AVIF are working on writing something compact that could be used to get the size of an AVIF image. If they succeed, I'll submit a patch for PHP 8.2.

Primary blocker is that AVIF contains more then one image but all image effects suppose only one image (kinga same we have with GIFs)

If this happens, how should we handle the fact that Drupal 9 goes EOL in the same month that PHP 8.0 goes EOL? Would we just say to PHP 8.0 users that sorry, unlike in the past, Drupal isn't providing any option to run any supported Drupal version on a PHP version that has only just now become EOL?

PHP's three year release cycle has only properly been in place since 2018, three years after Drupal 8 was released and only three years ago, so previous major Drupal versions aren't a direct comparison. It's very different to PHP 5 where sites had been able to run on PHP 4 for a decade. Every year it continues that churn, it becomes more of a status quo that all hosts, sites, and projects with PHP dependencies have to deal with on an ongoing basis. It still feels like a transitional period at the moment though (in the same way here are lots of Drupal 7 sites that would happily stay running on PHP 7.0 if it stayed supported).

Is this that much different though than this happening a month or two or six after we release 10.0?

If it's one month afterwards, then we could feasibly decide to release Drupal 10 on a release candidate of the dependency and update to stable in a patch release, or even slip the release date to a fallback if it seemed worth it. Assuming we know in advance that this is going to happen. Obviously that's no help we get a surprise two weeks after we release 10.0.0.

When it's six months either side, I do think that makes a lot of difference though yeah - because six months * 2 is equivalent to an entire PHP release.

Assuming we release Drupal 10 in June 2022, and Drupal 11 in June 2024:

If a dependency adds a major version with a PHP 8.1 dependency in December 2021, it's 2.5 years (or 0 years if we're prepared to raise our own requirement to PHP 8.1) before we can upgrade to it, and 4.5+ years (or 2.5+) before we can drop the previous major.

If a dependency adds a major version with a PHP 8.1 dependency in in December 2022, it's 1.5 years before we can upgrade to it, and 3.5+ years before we can drop support for the old major.

This is less about being able to adopt new PHP features in 2022, and more about enabling Drupal 10 to add basic support for new PHP versions as they're released over its lifetime into 2024 and 2025, as all the dependencies get longer in the tooth.

If we release Drupal 10 on Symfony 6, then the hard EOL is November 2027. This means the latest PHP version we could realistically deal with is PHP 8.6 (or 9.x equivalent) in November 2026, or PHP 8.5 in November 2025. The absolute minimum we can do is the same version that Drupal 11 releases on (8.3?? I'm getting confused just typing all this out, good luck to everyone who has to read it), but it would be nice to go one better than that if we can, to support LTS-to-LTS upgrades better.

if any of our non-Symfony dependencies add a new major release requiring PHP 8.1 between now and June 2022, then we'll be stuck on their previous major version for the entire Drupal 10 cycle, which would not be good

I checked core's direct runtime dependencies (so, not including dev dependencies or indirect dependencies) that we plan to keep in Drupal 10 (so, not including doctrine/reflection, laminas/laminas-feed, or symfony-cmf/routing) to see if I could find an example of them in the past releasing a new version within 6 months of a new PHP version and setting that latest PHP version as the minimum. I couldn't find any, but the closest example that I did find was:

• doctrine/annotations releasing 1.5 (a minor!) in July 2017 with a PHP 7.1 requirement (released in Dec. 2016).

so they could conceivably do something similar and release a new minor in early to mid 2022 with a PHP 8.1 requirement. I'm hoping we can deprecate annotation parsing in Drupal 10 (and switch to PHP 8.0 attributes instead), which would let us remove doctrine/annotations from Drupal 11, but that doesn't solve our current problem of still depending on them for Drupal 10.

Another potential risk is:

• psr/log: Although 1.x still supports PHP 5.3, 2.0.0 and 3.0.0 were both tagged on the same day in July 2021, with both of them requiring PHP 8.0. I have no idea if that's now going to be stable for a while, or if there's a risk of a 4.x coming soon with a PHP 8.1 requirement.

However, this is a very small library that we could fork if we had to.

There are some libraries that raise the PHP minimum in minor (or even patch) releases. However, they haven't dropped PHP versions that are still in active support when they've done this:

• laminas-diactoros: Released 2.5 in Nov. 2020 with a PHP 7.3 requirement.
• stack/builder: Released 1.0.6 in Jan. 2020 with a PHP 7.2 requirement.
• egulias/email-validator: "PHP version upgrade requirement will happen via MINOR (3.x) version upgrades of the library, following the adoption level by major frameworks."

These libraries seem very conservative:

• pear/archive_tar: Still supports PHP 5.2.
• masterminds/html5: Still supports PHP 5.3.
• composer/semver: still supports PHP 5.3.

These have had relatively recent major releases, and each of those releases supported at least the 2 latest PHP versions at that time:

• Twig: 3 came out in 2019 and supports PHP 7.2
• Guzzle: 7 came out in 2020 and supports PHP 7.2
• Typo3/phar-stream-wrapper: 3 came out in 2018 and supports PHP 7.0
• asm89/stack-cors: 2 came out in May 2020, supports PHP 7.0

I haven't found any discussion of new upcoming major releases for them.

Updated the issue summary based on my understanding of #23.

If we want to use nested attributes to solve removing our dependency on Doctrine annotations we might need nested attributes - which are only supported on PHP 8.1 -see #3252386: Use PHP attributes instead of doctrine annotations

Landed #3252088: Increase Drupal::MINIMUM_PHP to 8.0.0 just now.

It would be nice to be able to use PHP 8.1 language features in Drupal 10 minors, but this is a lower priority consideration than all of the above.

#3252386-35: Use PHP attributes instead of doctrine annotations makes a good argument for why this might be a higher priority consideration than as currently written.

It's good for Drupal to get a decent amount of early adoption of a new major Drupal version (i.e., the X.0 version), since that provides the ecosystem support for contrib modules to get upgraded.

#3223435-14: Track PHP 8.1 support in hosting and distributions seems to indicate that a PHP 8.1 requirement won't necessarily get much in the way of that.

Drupal 9 will go EOL in Nov. 2023, which is exactly when PHP 8.0 goes EOL. If Drupal 10 requires PHP 8.1, then PHP 8.0 users will have 0 grace period during which to remain on a just-EOL'd PHP version but still be able to run a supported version of Drupal.

The issue summary currently lists this as a higher priority consideration than the benefit of using new language features like nested annotations. However, it is worth noting that none of the major Linux distros will support PHP 8.0 past its EOL (e.g., Ubuntu 20.04 ships with PHP 7.4 and Ubuntu 22.04 will likely ship with PHP 8.1), so while some EOL PHP versions continue to be used by people, I'm not sure how much responsibility Drupal should have to accommodating users of an EOL PHP version that isn't even maintained by any Linux distro.

Given all of the above, I think we should consider setting a PHP 8.1 requirement, even if no vendor library does.

I have a couple of questions:

1. Given that with the earliest release of D10 the D9 site owners will have 18 month to migrate to D10. With the latest release of D10 the D9 site owners will have 12 months to migrate to D10. My question is can that all be done before D9 goes EOL and how much harder will it be for them if we change the minimum requirement of D10 to PHP 8.1?
2. Is there a Drupal dependency (regular or development) which will block the release of D10 when we change the minimum requirement to PHP 8.1?

Do not get me wrong, I am a developer and I like the shiny new stuff, only we also have a large number of D9 sites in production and they all need to be migrated to D10, before D9 goes EOL. Is it maybe an idea to ask non-developers what they think about changing the minimum requirement to PHP8.1. Especially in combination with the short migration window for D9 to D10.

Coming back here from #3252386-64: Use PHP attributes instead of doctrine annotations.

The main reason we have to require PHP 8.1 is to be able to drop Doctrine annotations in Drupal 11, this requires deprecating them no later than 10.4, but ideally providing an alternative earlier than that.

We can provide attributes as an option in core, using the preferred PHP 8.1-compatible syntax, without a PHP 8.1 requirement, as long as core still uses annotations (i.e. as early as in 9.4). Increasingly, a PHP 8.0-compatible syntax is looking much less than ideal and very complicated to support.

We don't know when Doctrine will drop support for annotations, probably not before Drupal 10 EOL, but maybe Drupal 11 or Drupal 12 EOL. There is no roadmap for Doctrine so all we have is guesswork.

We don't have to deprecate annotations in 10.0.x to remove it in Drupal 11, it could be somewhere between 10.1.x and 10.4.x, to deprecate annotations, core needs to stop using it, which means a PHP 8.1 requirement when we do.

I've been resistant to the idea so far, but I think this points to a two step process:

1. Announce, at the same time, prior to release of 10.0.0, that core will require PHP 8.0 in Drupal 10, but that we will strongly recommend PHP 8.1, and will drop PHP 8.0 support in the minor after official security support for it ends (December 2023 release window), probably 10.3.x.

2. In that minor, or possibly the one afterwards, adopt PHP 8.1 syntax (attributes), so that we can deprecate doctrine annotations for removal in Drupal 11.

This means you can install on PHP 8.0, but we will constantly warn you that you should upgrade soon. Some contrib modules may adopt attributes and PHP 8.1 earlier than core does, core will do it once PHP 8.0 is out of official security support. If we announce all this up-front and use the core recommended/minimum PHP versions from the start to communicate it, then it shouldn't be too much of a surprise when we drop PHP 8.0 support.

The PHP 8.1 requirement in 10.3.x-ish also provides us a bit of wiggle room if there's a 'major for them, minor for us' release of another dependency with a PHP 8.1 requirement that we would prefer to upgrade to rather than going out of support, at the point in the release cycle where we're mostly likely to need it.

My main concern with doing this previously, has been that #2917655: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4 has been open since 2017 for Drupal 9, completely unresolved. Also the potential for sites to get 'stuck' on a minor release, but the 12 month security support for each minor, and also starting off recommending PHP 8.1, both ameliorate that a bit. Generally, if we make and communicate the decision up front, then we're not springing it on anyone.

So we have 3 choices:

• Have a PHP 8.0 minimum for Drupal 10.0, and don't raise that until Drupal 11.0.
• Start with a PHP 8.0 minimum for Drupal 10.0, and raise that to PHP 8.1 in Drupal 10.3.
• Have a PHP 8.1 minimum for Drupal 10.0, and don't raise that until Drupal 11.0.

For this comment, I'll ignore #1 (I don't necessarily think we should rule it out, I'm only ignoring it for purposes of this comment). With respect to the last two options...

The advantages of PHP 8.0 for Drupal 10.0 and raising to PHP 8.1 for Drupal 10.3 are:

• People using hosting providers that won't offer PHP 8.1 until some time after Drupal 10.0 is released can still adopt Drupal 10.0 in the meantime. I don't know how valuable this would be for people with existing Drupal 9 sites, because Drupal 9.4 will have the same end-user features as Drupal 10.0, and if you have to do a 9 to 10 upgrade either way, why not just wait until 10.1. However, for new sites, as well as for sites migrating from Drupal 7 (which there might be a lot of in the June to November timeframe, considering Drupal 7 goes EOL in November), it might be valuable for those site owners to be able to start on Drupal 10.0 rather than having to start on 9.4 and then later having to upgrade to 10.
• Drupal 10.2 will be security supported until June 2024, whereas Drupal 9 goes EOL in November 2023. PHP 8.0 goes EOL in November 2023, but RHEL 9 might keep PHP 8.0 supported until May 2024 (I wrote #31 before learning about #3223435-18: Track PHP 8.1 support in hosting and distributions). Not sure how much we want to accommodate PHP 8.0 users between those two dates, but this option allows us to do it.

On the other hand, the advantages of starting with a PHP 8.1 minimum in Drupal 10.0 are:

• Core can start using PHP 8.1 syntax, including annotations with their full 8.1 capabilities, sooner, and feel more modern as a result. See #3252386-60: Use PHP attributes instead of doctrine annotations.
• Contrib modules can start using annotations (with their full 8.1 capabilities) sooner and with a clean conscience, rather than having to choose between either waiting until 10.3, or setting a higher PHP minimum than core does.
• We avoid the risk of a fragmented contrib ecosystem, where some contrib modules choose to require PHP 8.1 sooner in order to use annotations sooner, and other contrib modules wait until 10.3, and in the meantime, sites on PHP 8.0 have a reduced set of contrib modules available to them.
• We avoid the risk of people being surprised/upset about us raising the PHP minimum (which is kind of a BC break) in a Drupal minor release, where we generally promise not to break BC, but #33 provides for a way to minimize the risk of people being caught by surprise by this.

Honestly, I think it's a tough call. I think both sets of advantages are pretty compelling, each for their respective audiences.

Core can start using PHP 8.1 syntax, including annotations with their full 8.1 capabilities, sooner, and feel more modern as a result. See #3252386-60: Use PHP attributes instead of doctrine annotations.

I think this should be listed under both, since #3252386-64: Use PHP attributes instead of doctrine annotations would mean we can support PHP 8.1 attribute syntax in core right from 10.0.x (or even 9.4.x), the thing we'd be deferring is the conversion from annotations to attributes for core plugins, but not the nicer syntax in the discovery API.

We avoid the risk of a fragmented contrib ecosystem, where some contrib modules choose to require PHP 8.1 sooner in order to use annotations sooner

Requiring PHP 8.1 doesn't reduce the risk of contrib modules requiring PHP 8.1, it raises the 'risk' to exactly 100% of modules since they all would by default.

So the only issue is that it makes PHP 8.0 support potentially less comprehensive, but it would be less comprehensive compared to zero. The question then is are we more worried about sites not being able to install on PHP 8.1 at all (stuck on 9.4), or being on PHP 8.0 and forced to upgrade PHP version because a contrib module needs it or because they need to update to 9.3.0. My hope is that very clear messaging to install on PHP 8.1 in the first place, with PHP 8.0 supported as a last resort, would reduce the number of people who end up in that situation. It does make things more complex compared to just requiring PHP 8.1 up front, but seems a bit unbalanced in the comparison.

Some of our dependencies are adding attributes support already (https://github.com/sebastianbergmann/phpunit/issues/4502 and etc), or contrib may have its own dependencies that add attributes support, or they might start using attributes directly for some other reason, or other PHP 8.1 features like Fibers, and raise their requirement due to that.

Also, even if we kept a PHP 8.0 minimum for the entirety of the Drupal 10 cycle (I know you ruled it out of the comparison, but it's relevant for this specific point), we'd need to add PHP 8.1 attributes syntax support during the Drupal 10 cycle to be able to require it in Drupal 11, and the moment we do that, contrib modules have an extra reason to require PHP 8.1 too, even if core won't until Drupal 11 is out.

Re #36, my concern was more along the lines of the following:

• A contrib module has a D9-compatible branch (e.g., 1.x) and is being used on a bunch of D9 sites.
• That contrib module needs to make some changes to work with D10, and for whatever reason makes a new branch (e.g., 2.x) for it (either because it can't figure out a way to work with D9 and D10 simultaneously, or just because it has future plans to take advantage of new D10 features).
• It releases a 2.0.0-alpha1 that just has the minimal changes needed to work with D10. Doesn't convert annotations to attributes yet.
• A D9 site that's on PHP 8.0 upgrades to Drupal 10, because it can. In doing this, it upgrades to 2.0.0-alpha1 of the above module.
• That contrib module converts annotations to attributes because it's cool, sets a PHP 8.1 requirement, and releases 2.0.0-alpha2 (semver doesn't forbid breaking BC in alpha releases).
• The sites that upgraded to Drupal 10 are now stuck on an unsupported alpha1 release of that module.

However, if we can communicate to contrib maintainers our request for them to not do this, and make it easy for them to comply with that request, then I actually like the idea of a mid-D10 PHP bump, and added that as an option 5 to #3252386: Use PHP attributes instead of doctrine annotations. However, in that option, I propose the bump to happen in 10.2 rather than in 10.3, because bumping in 10.3 means responsible contrib modules still need to support 10.2 until 10.4 is released, which might also be when 11.0 is released, which doesn't give enough time in which to convert from annotations to attributes. Whereas bumping in 10.2 means that contrib modules can convert away from annotations when 10.1 is EOL, which more or less coincides with when Drupal 9 is EOL, meaning that the contrib maintainer wouldn't need to retain annotations for any longer than they already would have if they were planning to support D9 until its end.

because bumping in 10.3 means responsible contrib modules still need to support 10.2 until 10.4 is released, which might also be when 11.0 is released

This won't be the case if we're able to release 10.4 three months earlier than 11.0.0 as discussed in the two year release cycle issue (although that's also not agreed yet).

Symfony is considering bumping the minimum requirement to for 6.1 to 8.1 https://github.com/symfony/symfony/pull/45377

We could probably protest if we wanted to, but I think that's a sign we should just require PHP 8.1 and be done with it.

The Drupal core committers agreed today that Drupal 10 will require PHP 8.1. This is being implemented in #3264819: Require PHP 8.1 for Drupal 10.0.0-alpha2. A more detailed announcement will be forthcoming within the next couple of weeks. Thanks everyone for your help discussing this issue!