Switching to tilde constraints for controlled updates
Opened this issue · 2 comments
The current caret constraint ^10.2 allows versions >=10.2.0 <11.0.0. With the recent Drupal update to 10.3, projects using this template without a composer.lock file received Drupal 10.3 updates. This affected automated builds relying on this project as a consistent base for testing, causing builds to break without any code changes.
The existing constraints provide a convenient way for existing projects created using this project to avoid updating composer.json and only update composer.lock when new versions are released. This is beneficial.
However, for projects that are just starting, the composer.json contains 10.2 as a lower constraint that the team of this project must maintain. If a consumer project maintainer is unaware of the current version of Drupal, they might think they are getting 10.2 but actually receive 10.3.
Considering that minor Drupal versions have API changes and deprecations, there is a high chance that consumer project maintainers would not update their core minor versions automatically by only running composer update. They would need to ensure contrib modules work correctly with the new core version and perform testing. Thus, they would consciously update their composer.lock and possibly composer.json to include a new version of Drupal core rather than relying on a constraint. The convenience of the ^ caret constraint for non-Drupal PHP packages may not apply here.
Proposal
Switch to a tilde constraint for this project to receive versions >=10.2.0 <10.3.0 on consumer projects and automated builds. The project team will still update the version constraint in composer.json to the most recent Drupal version, but consumer sites (and automated builds) will have a more controlled environment.
The update process for the consumer site would now be:
- Update the version of the
drupal/core-*to~10.3incomposer.json - Run
composer update --with-dependencies
If we decide to stick with ^, we should at least describe this issue in detail so that project maintainers can make conscious decisions about how they receive updates.
Note: I've used 10.2 and 10.3 as example versions here, but the same will apply to any other minor versions in the future.
Note: you would need ~10.2.0 (or some explicit other last digit) to disallow ^10.3; see also https://getcomposer.org/doc/articles/versions.md#tilde-version-range-.