1
0
Fork 0
mirror of https://github.com/composer/composer synced 2025-05-09 00:22:53 +00:00
composer/doc/faqs/why-are-unbound-version-constraints-a-bad-idea.md
Jan Tojnar 955194f896
docs: Fix inconsist semver operator suggestion (#10810)
Using caret over tilde is better since it behaves the same as in npm:
https://jubianchi.github.io/semver-check/#/constraint/~3.0
But when this change was introduced in https://github.com/composer/composer/pull/5396,
it was not complete.
2022-05-31 13:24:38 +02:00

1 KiB

Why are unbound version constraints a bad idea?

A version constraint without an upper bound such as *, >=3.4 or dev-master will allow updates to any future version of the dependency. This includes major versions breaking backward compatibility.

Once a release of your package is tagged, you cannot tweak its dependencies anymore in case a dependency breaks BC - you have to do a new release, but the previous one stays broken.

The only good alternative is to define an upper bound on your constraints, which you can increase in a new release after testing that your package is compatible with the new major version of your dependency.

For example instead of using >=3.4 you should use ^3.4 which allows all versions up to 3.999 but does not include 4.0 and above. The ^ operator works very well with libraries following semantic versioning.

Note: As a package maintainer, you can help your users by providing an alias version for your development branch to allow it to match bound constraints.