Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.(This is a topic that has been raised in passing in a few other issues - but so that it does not get lost, it seemed like a good idea to create a separate issue).
There are (at least) two options for how we specify versions of dependencies in Drupal's core/composer.json:
<dependency> Major.Minor.*- what we're doing now.<dependency> Major.Minor.KnownGoodPatch1-Major.Minor.KnownGoodPatch2- specifying a range of known good patch versions.
And yes - Drupal already has a composer.lock in the repo - so generally speaking most users will get the exact version in the lock file. (And for security updates in dependencies they will need to manually composer update <dependency>.
However - in any project where Drupal core is just another component being required, and not the main composer project - Drupal's composer.lock will be ignored, and the larger projects composer.json will pull in dependencies from Drupal core's composer.json.
So with the wildcard patch versioning that is currently used - when Drupal is required in a larger project - the latest patch versions will be installed and added to the larger projects composer.lock. These may well be untested versions, which, even though a patch release SHOULDN'T break things, might break Drupal. This has happened before: see #2414235: Upgrade to Symfony 2.6.4. If we specify version ranges in composer.json - we can ensure that even when Drupal is required as part of a larger project - the dependencies are restricted to only patch versions that we have tested. However, if later patch versions of dependencies become desirable, users requiring Drupal would not get those versions unless Drupal has had a release with an updated composer.json with the expanded patch range OR they manually compser update <dependency> in their project. (A behavior which they will likely have to do from time to time anyway to respond to security releases).
Next Steps:
Answer the question:
Is it better to specify wild card patch versions of dependencies in composer.json and accept the possibility of a future patch release of a dependency(untested dependencies) breaking Drupal - or is it better to specify version ranges and understand that we will have to roll new releases to update that range?
Some additional reading:
http://stackoverflow.com/questions/25055161/composer-two-packages-confli...
http://stackoverflow.com/questions/21052831/how-to-solve-two-packages-re...
https://github.com/composer/composer/issues/2609
Comments
Comment #2
hestenetSome notes on this issue from a community composer call - where the conversation leaned heavily away from specifying ranges in core:
@Jordi(of Packagist): I think the best solution is: Run a daily test of the latest release against the latest versions of all dependencies - that will at least alert you if a patch level change in a dependency broke something and you can roll a patch release or whatever is needed.
@Webflo: Alternately - we could use this new idea of meta-packages. By converting the drupal core composer.lock into a meta-package..
Comment #3
webflo CreditAttribution: webflo at UEBERBIT GmbH commentedThe strict core build script is available on https://github.com/webflo/drupal-core-strict and https://packagist.org/packages/webflo/drupal-core-strict
Comment #17
Mile23We eventually settled on open-ended constraints (not a range).
We also added a drupal/core-recommended metapackage which is basically the core lock file.
Marking this as closed, outdated.
Comment #18
Mile23