Preparations
I decided to go with small steps, version after version so that I don't end up in a big code mess or dependency hell. It is also nicer to "document" all changes with small meaningfull commits.
First thing that Symfony recomends is to get rid of all deprecations. In debugger toolbar it is easy to see all deprecated messages. Fortunatelly, not all of them were on a project level and for those that were not, hopefully they would dissapear after updating symfony and 3rd party vendors. After fixing deprecations from my codebase, I was ready to move on.
Before upgrading to next minor version (4.4), I ran composer update just to be sure that all packages are up to date until restricted version numbers.
Another thing which was important was to unpack the symfony packages. The problem is that these packages mask the real dependencies (http://fabien.potencier.org/symfony4-unpack-the-packs.html). Specifically, there was an issue with "symfony/orm-pack" which was requiering latest doctrine/orm version (version 3.*) that was not compatible with other depencencies and it was impossible to downgrade it to version 2 without unpacking the "symfony/orm-pack" first.
Upgrading Symfony to 4.4
To upgrade Symfony, one has to change the versions of symfony packages inside of composer.json. Fortunately, Symfony is keeping package versions in a sync so that you don't have to wonder which package versions are compatible with each other. For example, "symfony/asset": "4.3." would need to be changed to "symfony/asset": "4.4.", and so on. In the end, there is also one more directive in composer.json comming from symfony/flex plugin which restricts the packages to be upgraded only to certain version of Symfony. This directive can be found under "extra": { "symfony": "require": "4.3." } and also needs to be changed to "4.4.".
Now everything is ready for the actuall upgrade which is executed by running composer update "symfony/*" or even better composer update "symfony/*" --with-all-dependencies which will also upgrade other packages which might depend on symfony libraries.
Next milestone, Symfony recipes
Before proceeding to the next version (major) it is recommeded that you also update your recipes. As packages evolve, it is possible that their recipes change as well. The problem here is if you decide to update the recipe, it will override your custom changes (if you have any). And it's very likely that you do, as I had as well.
Before continuing I made sure that I have clean repo with all previous changes commited. The plan was to update the recipe one by one, and after each update to check with git diff what did the recipe change and correct this change in a way that my previous configuration stays intact, or that it is properly migrated to fit the new recipe.
So, first I executed composer recipes to get a list of available recipes and also to see which of them have update available. After that, composer recipes:install {PACKAGE_NAME} --force -v did the actal update.
Next git diff revealed the change made, and I altered the config accordingly,
and finally, git commit -am "Update {PACKAGE_NAME} recipe" to commit the change.
Upgrading Symfony from 4.4 to 5.0
Same as with 4.3 -> 4.4 upgrade, I started by changing all symfony package versions from 4.4. to 5.0.. But after running composer composer update "symfony/*" --with-all-dependencies there was a couple of issues:
Problem 1:
- The requested package symfony/web-server-bundle 5.0.* exists as symfony/web-server-bundle[... v4.4.9] but these are rejected by your constraint.
Problem 2:
- knplabs/knp-paginator-bundle v4.1.1 requires symfony/framework-bundle ^3.4 || ^4.0 -> satisfiable by symfony/framework-bundle[v4.4.19] but these conflict with your requirements or minimum-stability.
Checking the symfony/web-server-bundle I figured out there is no such version (5.0) for this package. The latest version is 4.4.9. so it looks that by doing the verison replacement in composer.json I also changed this one to 5.0. So, I just reverted the version number to 4.4.. Running `composer update "symfony/" --with-all-dependencies` left me with one problem less, so this was fixed.
Next problem is with "knplabs/knp-paginator-bundle" and after checking the "knplabs/knp-paginator-bundle" release logs I found out that they added support for Symfony 5 in version 5.0. So I changed the "knplabs/knp-paginator-bundle" version to "^5.0" and tried again. However, this didn't help, I kept getting the same message. Aparently there was some issue with this package so I decided to upgrade it separately before upgrading symfony and see if it helps. However, to be able to do that I had to temporarily revert symfony package versions back to 4.4 otherwise the update would fail. This did work indeed so I changed Symfony package versions back to 5.0 and tried again.
Now, the new problem arose: oneup/uploader-bundle 2.2.0 requires symfony/asset ^3.0|^4.0 -> satisfiable by symfony/asset[v4.4.19] but these conflict with your requirements or minimum-stability.
Again, checking the release logs of the library revealed that in version 3.0 they added support for Symfony 5.0. so I reverted symfony package versions to 4.4, executed composer require "oneup/uploader-bundle:^3.0" and indeed, the package was correctly updated.
This time, changing Symfony package versions to 5.0. again and running `composer update "symfony/" --with-all-dependencies` updated symfony succescfully! Finally.
All good except one minor issue: after clearing the cache I got: "Unable to find file @TwigBundle/Resources/config/routing/errors.xml". Luckilly this file just moved to @FrameworkBundle so I updated config/routes/dev/twig.yaml replacing @TwigBundle with @FrameworkBundle.
Now that the upgrade was through, I started the tests to see if everything is working, and indeed it found an issue:
- Cannot use the "format" option of "Symfony\Component\Form\Extension\Core\Type\DateTimeType" when the "html5" option is enabled.
Since I'm using EasyAdmin for my admin area in this project, I checked the easy_admin.yaml configuration and quickly found that there is a field using 'datetime' type, so I passed additional option html5: false to disable html5 option so that "format" option can be used.
Upgrading Symfony from 5.0 to 5.2
This went without any incident. First I changed composer.json versions from 5.0. to 5.1. and executed composer update "symfony/*" --with-all-dependencies
After that there were just couple of recipes to update.
Then same thing again, only from 5.1. to 5.2..
To summarize:
- do upgrades in small steps
- first get rid of deprecations
- after upgrade, update recipes
- if there is an issue with dependency, check the release logs and update it accordingly
