Problem/Motivation
Today, whenever a patch includes an updated composer.lock
file, the dependencies in that lock file are calculated using whatever PHP version the patch submitter happens to be using. This means that the generated dependency graph might be different depending on who generated the patch file. Worse than that, some results might actually be erroneous. Erroneous results might result in a failure from the composer update command, or, worse still, might produce dependencies that do not work with the advertised minimum version of Drupal. Some of these erroneous results would not be caught by the tests.
One example where this used to go wrong in Drupal 9.0.x related to the minimum PHP version in the drupal/drupal composer.json file. At the time, PHP 7.2.3 is required; however, if you installed this version of PHP and run composer update
, you got an error:
Problem 1
- symfony/mime v5.0.0 requires php ^7.2.5 -> your PHP version (7.2.3) does not satisfy that requirement.
In addition to symfony/mime, there were other packages with minimum PHP versions that are higher than when 7.2.3 was originally selected as the minimum for Drupal 9.x. For example, symfony/service-contracts
v2.0.0 requires php ^7.2.9.
Proposed resolution
- Set the minimum version of PHP explicitly to 7.3.0, so that the version that we declare as our minimum matches what our dependencies require.
- Set
config.platform.php
in the drupal/drupal root-level composer.json file to match the minimum PHP version in core/composer.json, so that dependency resolution is always done consistently, regardless of the version of PHP installed on the machine running thecomposer update
command. - Add an integration test that ensures that the version of PHP stipulated in
config.platform.php
always matches the minimum version of PHP in core/composer.json, so that the tests will always catch any mistakes that may be made updating one of these without the other.
Note that since the minimum version of PHP 7.3 is currently 7.3.0, and there is no PHP 7.3 version lower than 7.3.0, the safeguards in this patch are currently unnecessary. However, if we include these tests now, it will protect us from errors similar to those described above once Drupal 9 starts requiring dependencies with higher patch versions of PHP 7.3.
Remaining tasks
We need to decide if this should be backported to the 8.9.x and/or the 8.8.x branches. In theory, the dependency versions on these branches should no longer change very often. However, it is possible that they might, e.g. due to a security update. With PHP 7.0 and 7.1 both being at EOL, some projects may decide to drop support for them in a minor or patch release. (I personally recommend against this, but it may happen.) Having this backported to the earlier branches therefore might be helpful, even though the odds of needing it there are fairly low.
Follow-on Work
User interface changes
None.
API changes
None.
Data model changes
None.
Release notes snippet
n/a