Most PHP projects eventually pull in open source libraries from Composer. All of these Composer dependencies must be updated regularly to avoid security holes or incompatibility issues with new software. I do a couple of things before updating a dependency to make sure the update doesn't break anything.

Figuring out what might break

Some Composer packages provide a file, which is a great way to know if updating will break a website. But reading through dozens of changelogs can take a long time. Because most Composer packages (or at least well known ones) rely on SemVer to publicize what might have changed between two releases, there is usually no need to read through changelogs.

SemVer says that any software packages should have a version of the form <major>.<minor>.<patch>, for instance 5.1.34.

Whenever the major part changes, there is a breaking change in the package. In that case, I verify if any code is affected and needs to be updated. Whenever the minor part changes, there shouldn't any breaking change but in practice, I've seen breaking changes for minor updates, I prefer to read the changelog. I have very rarely seen breaking changes with patch updates, although they can happen if the code relies on the bugged behavior.

Viewing composer version changes after an update

To get an overview of version changes after a composer update, I use git diff and grep:

git diff composer.lock | grep -B1 -E '            "version"'

The output looks like this:


From there, I take a closer look at the changelogs from packages for which a major or minor version has changed.