Upgrading a Major Version (e.g. 6.4.0 to 7.0.0) (Symfony Docs)

Every two years, Symfony releases a new major version release (the first number changes). These releases are the trickiest to upgrade, as they are allowed to break backward compatibility. However, Symfony makes this upgrade process as smooth as possible.
This means that you can update most of your code before the major release is actually released. This is called making your code future compatible.
There are a couple of steps to upgrading a major version:
During the lifecycle of a major release, new features are added and method signatures and public API usages are changed. However, minor versions should not contain any backwards incompatible changes. To accomplish this, the "old" (e.g. functions, classes, etc) code still works, but is marked as deprecated, indicating that it will be removed/changed in the future and that you should stop using it.
When the major version is released (e.g. 7.0.0), all deprecated features and functionality are removed. So, as long as you've updated your code to stop using these deprecated features in the last version before the major (e.g. 6.4.*), you should be able to upgrade without a problem. That means that you should first upgrade to the last minor version (e.g. 6.4) so that you can see all the deprecations.
To help you find deprecations, notices are triggered whenever you end up using a deprecated feature. When visiting your application in the dev environment in your browser, these notices are shown in the web dev toolbar:
Ultimately, you should aim to stop using the deprecated functionality. Sometimes the warning might tell you exactly what to change.
But other times, the warning might be unclear: a setting somewhere might cause a class deeper in the code to trigger the warning. In this case, Symfony does its best to give a clear message, but you may need to research that warning further.
And sometimes, the warning may come from a third-party library or bundle that you're using. If that's true, there's a good chance that those deprecations have already been updated. In that case, upgrade the library to fix them.
Rector is a third-party project that automates the upgrading and refactoring of PHP projects. Rector includes some rules to fix certain Symfony deprecations automatically.
Once all the deprecation warnings are gone, you can upgrade with a lot more confidence.
When you run your tests using PHPUnit, no deprecation notices are shown. To help you here, Symfony provides a PHPUnit bridge. This bridge will show you a nice summary of all deprecation notices at the end of the test report.
All you need to do is install the PHPUnit bridge:
Now, you can start fixing the notices:
Once you've fixed them all, the command ends with 0 (success) and you're done!
Using the Weak Deprecations Mode
Sometimes, you can't fix all deprecations (e.g. something was deprecated in 6.4 and you still need to support 6.3). In these cases, you can still use the bridge to fix as many deprecations as possible and then allow more of them to make your tests pass again. You can do this by using the SYMFONY_DEPRECATIONS_HELPER env variable:
You can also execute the command like:
Once your code is deprecation free, you can update the Symfony library via Composer by modifying your composer.json file and changing all the libraries starting with symfony/ to the new major version:
A more efficient way to handle Symfony dependency updates is by setting the extra.symfony.require configuration option in your composer.json file. In Symfony applications using Symfony Flex, this setting restricts all Symfony packages to the given version constraint, improving both dependency management and Composer update performance:
Set this option to a version constraint such as 7.0.* or ^7.0, not to an exact version such as 7.0.1. Otherwise, the update fails when a Symfony package has no release with that exact version or when a security advisory blocks it.
If a package in the require section uses a constraint that doesn't intersect with extra.symfony.require, Flex keeps that constraint and displays a warning. This lets you require a development version of some package (e.g. dev-main); Flex doesn't display the warning for these constraints.
Tools like dependabot may ignore this setting and upgrade Symfony dependencies. For more details, see this GitHub issue about dependabot.
If a more recent minor version is available (e.g. 6.4) you can use that version directly and skip the older releases (6.0, 6.1, etc.). Check the maintained Symfony versions.
Next, use Composer to download new versions of the libraries:
A best practice after updating to a new major version is to clear the cache. Instead of running the cache:clear command (which won't work if the application is not bootable in the console after the upgrade) it's better to remove the entire cache directory contents:
If you get a dependency error, it may mean that you also need to upgrade other libraries that are dependencies of the Symfony libraries. To allow that, pass the --with-all-dependencies flag:
This updates symfony/* and all packages that those packages depend on. By using tight version constraints in composer.json, you can control what versions each library upgrades to.
If this still doesn't work, your composer.json file may specify a version for a library that is not compatible with the newer Symfony version. In that case, updating that library to a newer version in composer.json may solve the issue.
Or, you may have deeper issues where different libraries depend on conflicting versions of other libraries. Check your error message to debug.
Another issue that may happen is that the project dependencies can be installed on your local computer but not on the remote server. This usually happens when the PHP versions are different on each machine. The solution is to add the platform config option to your composer.json file to define the highest PHP version allowed for the dependencies (set it to the server's PHP version).
You may also want to upg