By xjm on
Change record status: 
Published (View all published change records)
Project: 
Drupal core
Introduced in branch: 
9.4.x
Introduced in version: 
9.4.0
Issue links: 
https://www.drupal.org/node/3198340
Description: 

The drupal/core-recommended metapackage now allows patch-level updates for dependencies. This means that site owners using drupal/core-recommended can now install most Composer dependency security updates themselves, without needing to wait for an upstream release of Drupal core that updates the affected package.

Before

In Drupal 9.3 and earlier, the metapackages pin dependencies to an exact patch version. For example, in 9.3.15, the constraint for composer/semver in the metapackage's requirements was:

        "composer/semver": "3.2.6",

The exact constraint meant that, even when composer/semver 3.2.7 was released, sites using the core-recommended package could not install version 3.2.7 without temporary workarounds (like aliasing the version or depending on drupal/core directly instead).

After

Beginning in Drupal 9.4, the core-recommended package's dependency constraints are set to a patch version with a ~. For example:

        "composer/semver": "~3.2.6",

This constraint will allow the package to be updated from 3.2.6 to 3.2.7 or 3.2.8 (etc.), but not to 3.3.0 or higher. To update the dependency, sites using core-recommended will simply need to run:

composer update composer/semver

Impact on sites built with tarballs

Drupal 9.4+ sites built with tarballs will no longer be receiving the same level of security support for core dependencies. Going forward, if core is not known to be exploitable, the core tarballs' dependencies will be updated within a few days (if contrib is known to be vulnerable) to a few weeks (if the vulnerability is uncommon or theoretical).

Sites built with tarballs should convert to using drupal/core-recommended in order to be able to apply security updates more promptly than the above timeframe.

Handling conflicts with upstream updates

Rarely, an upstream Composer dependency's patch-level update may introduce a regression for Drupal sites. When this happens, Drupal core will usually declare a conflict with the affected package version; however, these changes might not be immediately available in a core release. Site owners should test their updates before deploying.

If a dependency update does cause a regression, site owners can also add a top-level requirement for the known-good version. For example, if a site encountered regressions with composer/semver 3.2.8, but 3.2.7 worked appropriately, the site owner can run:

composer require composer/semver 3.2.7

Then, if a later update in 3.2.9 resolved the issue, the site could run:

composer remove --no-update composer/semver
composer update composer/semver
Impacts: 
Site builders, administrators, editors
Distribution developers
Updates Done (doc team, etc.)
Online documentation: 
Not done
Theming guide: 
Not done
Module developer documentation: 
Not done
Examples project: 
Not done
Coder Review: 
Not done
Coder Upgrade: 
Not done
Other: 
Other updates done

Comments

gapple’s picture

gapple
he/they
Primary language English
commented

To prevent updating to a version with a known regression, an alternative to requiring a specific version in a project's root composer.json with composer require is to add a conflict rule. When a new release of the package is available, composer update will skip the conflicting version and update to the latest without needing to remove the pinned requirement first.

    "conflict": {
        "composer/semver": "3.2.7",
    }