Update PHP supported versions

I would prefer to be strict about the supported PHP versions and only list the versions that we actually run tests on.

Please also check whether GitLab CI uses PHP 8.5 in the highest build before marking this as ready for review.

As a general rule of thumb, we prefer to stick with the recommended PHP versions for Drupal core, since the latest versions can sometimes introduce compatibility issues.

It might be even better to remove the PHP line entirely, just focus on compatibility with whatever Drupal core supports.

You can extend the automated tests to cover for additional PHP versions, if you're that concerned about it.

My approach to version constraints comes from maintaining a product that has lived on top of Drupal core since the early 8.0.0 days along with several external libraries. A framework might officially support a new PHP version, but that does not guarantee that every dependency in its version ranges, or any third party libraries my own package relies on, is ready for that PHP version.

I try to keep things consistent across all my packages, so I follow the same rules everywhere instead of making one-off exceptions.

I have also been burned in the past by breaking changes introduced in PHP minor releases. That experience taught me a simple rule: saying no is temporary, saying yes is permanent. If I mark a release as compatible with PHP X, Composer is free to install that release at any point in the future. Even if later versions tighten their constraints, that older tagged release will always remain available in dependency resolution.

I see lots of fun here #3523596: [meta] PHP 8.5 support.

Gitlab CI also just got PHP 8.5 support as opt-in #3513062: Allow opt-in PHP 8.5 testing.

There is also a concept in Drupal core, called recommended PHP version. Which is still PHP 8.4.

https://github.com/drupal/core/blob/11.3.0-rc1/lib/Drupal.php#L135

PHP 8.5 is only "supported" by Drupal core 11.3.x. --- btw, flagging a PHP support also means that test suites passing, not just the runtime works, and breaking changes usually occur in the testing layer (PHPUnit, Drupal core test base classes, etc).

https://www.drupal.org/docs/getting-started/system-requirements/php-requ...

Max PHP is still PHP 8.4.x on the CI

See in latest builds.
PHP 8.4.15 (cli) (built: Nov 18 2025 19:40:48) (NTS)

To be able to run checks on PHP 8.5 **manually**, I would have to create my own template variant and keep maintaining it. I am not sure if I like the cost implicates of that, probably I would rather wait until max PHP becomes PHP 8.5 on the pipeline.

https://project.pages.drupalcode.org/gitlab_templates/info/variants#vari...

PHP 8.4.17 (cli) (built: Jan 18 2026 19:54:24) (NTS)

The build, still runs on 8.4.x

andypost  [10:33 PM]
Rolled out CI PHP images 8.4.19/8.5.4

https://drupal.slack.com/archives/C51GNJG91/p1773351238652639

Maybe it is time to reevaluate

Max PHP build is still: PHP 8.4.19 (cli) (built: Mar 12 2026 21:22:27) (NTS)

While I appreciate your correctness and can understand the reasons for your decisions for this strict limitation, I have to report you from the view of a site admin of various websites.
This decision is making lifes extremely difficult. In fact, in all of our latest projects that come along with the default set of contrib modules we use regularly, the codebase would be generally good 8.5 compatible, but this module is the only one that brings some level of extra complication with this. I've to add an argument to all composer calls, both locally in dev as well in our deployment scripts.

I still need a PHP 8.4 deprecation patch for one of the other contrib modules, but having a patch included in the composer.json is easier maintainable then working around hard limitations. I think, any site builder, that is brave enough to use a quite new and young PHP version, is used to double-check compatibility, install patches, etc. It's nearly inevitable to patch the one or other module - having said this, it seems to me that the jump from 8.4 to 8.5 is quite minor in terms of typical code sitting in Drupal moduels

I wouldn't try to run a website on a very new PHP version, without checking the codebase with phpcompatibility/php-compatibility. I even check this for our projects, when we use or update to 8.4

Might it be worth just removing the PHP line from composer.json? Is there reason to note it there?

+1 for Damien's proposal

You have made valid points and I was seriously considering whether version pin should be dropped or how it could be kept.

However, the good news is that I have seen on another project that PHP 8.5.5 should be available on the CI, so if this build is going to use that, I am just going to merge the open MR

(This buys me time until PHP 8.6.0 is out to think about version pins :) )

Add so the OPT_IN_TEST_NEXT_MAJOR build used PHP 8.5 on that other project... meh.

PHP 8.5.5 (cli) (built: Apr 10 2026 19:28:11) (NTS)

:totoro:

great news! thanks