A few days ago, the Doctrine team released new versions of many
packages, dropping support for PHP 5.6 and 7.0, as well as HHVM. The
affected packages are:
- doctrine/common 2.8.0
- doctrine/dbal 2.6.0
- doctrine/collections 1.5.0
- doctrine/inflector 1.2.0
- doctrine/cache 1.7.0
- doctrine/instantiator 1.1.0
- doctrine/annotations 1.5.0
Since many people are encountering issues with these updates, here are a
few suggestions to ensure your code continues working as usual.
Composer version constraints
Chances are your version constraints in
composer.json look something
^2.5 constraint resolves to:
>= 2.5.0 && <= 2.999999.999999.
This is intended: our projects all follow Semantic
Versioning, so you can safely install a new minor
version without having to fear BC breaks.
When determining what version to install, composer employs a SAT solver
to make sure all dependencies are fulfilled. In our example above, the
SAT solver finds a version newer than 2.5 that satisfies all
Making sure you get a compatible version
When you run
composer update the next time, you'll automatically
receive updates for the packages mentioned above, provided that you are
running on PHP 7.1. If you are running an older PHP version, composer
will not install a version that requires PHP 7.1, since its requirements
are not fulfilled.
A common problem is people running a newer PHP version on their
developer machines than on their production servers. In this case,
composer update on a developer machine (with PHP 7.1) might
happily pull in an update that simply won't work when deployed on a
production machine running PHP 5.6.
To make sure this doesn't happen to you, there are two choices:
composer update on a machine with the same PHP version that
you use in production
- use the
config setting in
composer.json to override your local PHP
Why dropping PHP support in a minor version is not a BC break
One question we frequently hear is, "isn't dropping support for a PHP
version a BC break"? In a nutshell, no. A BC break happens when there is
an incompatible change that your package manager can't handle. For
example, changing a method signature in a minor version is a no-go,
since the composer version constraints mentioned above assume any minor
upgrade can safely be used.
However, when we drop support for an older version of PHP, composer will
not consider the new version if the PHP version requirement is no longer
fulfilled. Thus, you won't end up with a fatal error due to a wrong
method signature, you just won't get the new version.