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

[normanlolx]

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.

[normanlolx]

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.

[AlexSkrypnyk]

@normanlolx
The point I've made above was that a user would not update the minor version through an automated dependency update mechanism because of BC changes - those updates would never succeed.

But if we provide a tilde constraint - then the automated updates will be able to handle patch versions of the core because those would not have the BC changes.

I have been using this Renovate configuration on all my projects successfully without having those broken builds for minor because I use the tilde constraint.

[normanlolx]

@AlexSkrypnyk - Yeah, I also started to think it gets more and more important to be a bit stricter about the versioning.

So let's say we do this:

Would we provide the MR for every minor version bump ourselves then? Or can we automate this?

[AlexSkrypnyk]

oh, if you mean - for this repo - we could automate this, but it may become a bit confusing because our renovate/dependabot config will be asking to increment the minor numbers in the composer.json of this repository and users may think that this is what they need to use in their projects (where they may increment patches, but this is not needed, since composer.lock will be holding the version).

But maybe we can put a comment in that renovate/dependabot config to mention that it is used only for maintaining of this repo and should not be used in their sites.

I suggest we do it and even make it auto-merge those since they will be just updating what Drupal releases officially, so no risk there and less manual labour for us.