OXIESEC PANEL

Name	Size	Modified	Perms
📁 ..	-	07/20/2024 06:32:22 AM	rwxr-xr-x
📄 how-do-i-install-a-package-to-a-custom-path-for-my-framework.md	1.79 KB	01/31/2018 03:28:18 PM	rw-r--r--
📄 how-to-install-composer-programmatically.md	1.38 KB	01/31/2018 03:28:18 PM	rw-r--r--
📄 how-to-install-untrusted-packages-safely.md	938 bytes	01/31/2018 03:28:18 PM	rw-r--r--
📄 should-i-commit-the-dependencies-in-my-vendor-directory.md	1.66 KB	01/31/2018 03:28:18 PM	rw-r--r--
📄 why-are-unbound-version-constraints-a-bad-idea.md	1.06 KB	01/31/2018 03:28:18 PM	rw-r--r--
📄 why-are-version-constraints-combining-comparisons-and-wildcards-a-bad-idea.md	998 bytes	01/31/2018 03:28:18 PM	rw-r--r--
📄 why-can't-composer-load-repositories-recursively.md	2.06 KB	01/31/2018 03:28:18 PM	rw-r--r--

Editing: why-are-unbound-version-constraints-a-bad-idea.md

# 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](https://semver.org).

**Note:** As a package maintainer, you can make the life of your users easier
by providing an [alias version](../articles/aliases.md) for your development
branch to allow it to match bound constraints.