Switching to tilde constraints for controlled updates

[AlexSkrypnyk]

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:

1. Update the version of the drupal/core-* to ~10.3 in composer.json
2. 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.

[jnoordsij]

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-.

[AlexSkrypnyk]

@webflo @leymannx
Could you please let me know your thoughts about this proposal. thanks

[AlexSkrypnyk]

I've been using this new way on many projects currently and it has proven to be a good way to prevent accidental updates.

[AlexSkrypnyk]

@leymannx @webflo
Could you please let me know your thoughts about this proposal. thanks

[leymannx]

I'm not a 100% convinced by this. I expect people to understand that bit of semantic versioning to understand that they will always get the latest Drupal in a branch with the circumflex character.

I also don't like needing to manually update composer.json for minor core updates.

Biggest downside in m opinion is that we would need to maintain the composer.json more often.

But on the other hand I've also seen more breaking changes in minor versions than in the past and I also see other people wanting more fine-grained control of the version installed.

[AlexSkrypnyk]

I have used the tilde version in several projects in conjunction with automated updates for dependencies and it worked really well.

I have yet to see a single minor Drupal core update on a consumer site that would not require an additional code change, meaning that minor Drupal updates require manual intervention in most cases. Changing the version in composer.json is trivial compared to changes required to the rest of the codebase.

My concern is that people may think that minor core updates are similar to contrib updates but in reality they have BC changes. Especially with D11 deprecations.

[leymannx]

Yeah but then we maybe leave that to the users of that project.

Either this or that you'll probably find users being confused by either way. Some by updating too far, some by not being able to update anymore the way they are used to.

If you find a way to automate this, like a dependency bot providing the MR for every minor release, I'd be willing to give it a try though.