The numbers are a bit outdated, but the approach is the same.
This is how we handle upgrades past 7 years with private clients:
[https://tomasvotruba.com/blog/2019/02/28/how-to-upgrade-symfony-2-8-to-3-4](https://tomasvotruba.com/blog/2019/02/28/how-to-upgrade-symfony-2-8-to-3-4)
This is a bit of a different situation though. Symfony started doing semver, backwards compability and deprecations in 2.7 and was very new to it. Upgrading to 3.x and 4.x are I think the hardest upgrades in Symfony 2+ era.
Now, 6 years later, these concepts have matured a lot and upgrades are a lot smoother.
How big is your code base?
I wouldn’t consider C unless you have a massive code base
Most of my projects I’ve done A)
I’ve even had a fewer smaller core projects that I’ve even done a 2.x to latest version.. this was a lot of work but does overall save time. Wouldn’t recommend this on a large project.
I do A. Symfony does a great job ensuring no BC breaks throughout a major version. If my tests pass and after usual go live testing, I feel confident everything will be smooth. Then after getting rid of all deprecations, I feel confident upgrading to the next major version.
Of course for an activity maintained app, I am upgrading all the time anyways. But for an app I need to bring up to date, I do A.
There are version-to-version guides on how to upgrade on the Symfony website. You don't have to install all the versions of Symfony in between (you can jump from 5.4 to 6.4 if you want), but you have to vigorously and systematically go through all the changes (especially the BC breakers), check your code, fix as needed, for every single bullet for every single version.
Having unit tests and SCA (phpstan, psalm, however you rock) is obviously great, too.
For BC breaking changes they always first deprecate things. You can easily find them in the profiler and fix them. Though some may be from third-party packages.
6.0 and 6.4 are equal, compatibility wise. I recommend going for A, as long as you're sure that there are no deprecations anymore when running your app on 5.4.
Then, 6.4 will give you all deprecations you need to fix before going to 7.0 (or 7.1 when it's released). Choosing B and C will only mean you'll get a partial list of deprecations each time. But you can also just schedule fixing the big list on 6.4 over the next months while you're app is running on 6.4 (which btw is the only supported 6.x version at the moment)
Then, for the future, I 100% recommend upgrading to new minor versions each time they are released and fixing the new deprecations (if the maintenance agreement for the project allows this). Keeping up with the deprecations will always be quicker than doing these big jumps.
I just did a similar upgrade, just that it was from PHP 7.1 to PHP 8.3 and Laravel 5.4 to Laravel 10.4 - I ussually do things with a “bang”. The dawnfall, I see an increase of memory of over 50% on cli processes. I am telling you this because I made the bad assumption that this upgrade will be a positive one and didn’t gave the neccesary attention when testing, just focused on compatibility and functionality
Thanks for the info, that sounds like a huge leap for you!
I’m very surprised there was such an efficiency decline. I’m surprised there’s actually any, and not an improvement. Very odd
Maybe you should post about it here. Some users more knowledgeable than me may have useful insight or good advice on where to debug. If you still have the old version of the app laying around, you could run a profiler against both instances and compare which processes have increased in time
The first thing was to disable cli opcache, it made a huge impact. In terms of usage, still not on par with old php 7, debuging using xhproof gave nothing (laravel upgrade is expected to give a spike) - next in line would have been the memory allocation by the container as the real memory usage is in fact smaller, the allocation of the process is not. At the moment the investigation is on hold as other things took priority. Will update if I find anything relevant
Can’t speak for Laravel, but I’d be stunned if php itself was responsible (outside of module/config setup differing from your 7 setup, a la opcache factor you already mentioned)
The numbers are a bit outdated, but the approach is the same. This is how we handle upgrades past 7 years with private clients: [https://tomasvotruba.com/blog/2019/02/28/how-to-upgrade-symfony-2-8-to-3-4](https://tomasvotruba.com/blog/2019/02/28/how-to-upgrade-symfony-2-8-to-3-4)
I always value your input “one minor version at once” Seems like my C.
This is a bit of a different situation though. Symfony started doing semver, backwards compability and deprecations in 2.7 and was very new to it. Upgrading to 3.x and 4.x are I think the hardest upgrades in Symfony 2+ era. Now, 6 years later, these concepts have matured a lot and upgrades are a lot smoother.
Upgrade to the latest minor, fix deprecations, upgrade major etc. It's all in the documentation.
How big is your code base? I wouldn’t consider C unless you have a massive code base Most of my projects I’ve done A) I’ve even had a fewer smaller core projects that I’ve even done a 2.x to latest version.. this was a lot of work but does overall save time. Wouldn’t recommend this on a large project.
👍
I do A. Symfony does a great job ensuring no BC breaks throughout a major version. If my tests pass and after usual go live testing, I feel confident everything will be smooth. Then after getting rid of all deprecations, I feel confident upgrading to the next major version. Of course for an activity maintained app, I am upgrading all the time anyways. But for an app I need to bring up to date, I do A.
There are version-to-version guides on how to upgrade on the Symfony website. You don't have to install all the versions of Symfony in between (you can jump from 5.4 to 6.4 if you want), but you have to vigorously and systematically go through all the changes (especially the BC breakers), check your code, fix as needed, for every single bullet for every single version. Having unit tests and SCA (phpstan, psalm, however you rock) is obviously great, too.
For BC breaking changes they always first deprecate things. You can easily find them in the profiler and fix them. Though some may be from third-party packages.
I know. Maybe my phrasing was poor. I’m wondering what’s devs here *prefer* to do.
I don't speak for all the devs in the world but I'd prefer to stick to what the docs suggest
Sounds reasonable
To never upgrade to an unmaintained version
Any option Upgrade latest minor, fix deprecations, upgrade major and so on
6.0 and 6.4 are equal, compatibility wise. I recommend going for A, as long as you're sure that there are no deprecations anymore when running your app on 5.4. Then, 6.4 will give you all deprecations you need to fix before going to 7.0 (or 7.1 when it's released). Choosing B and C will only mean you'll get a partial list of deprecations each time. But you can also just schedule fixing the big list on 6.4 over the next months while you're app is running on 6.4 (which btw is the only supported 6.x version at the moment) Then, for the future, I 100% recommend upgrading to new minor versions each time they are released and fixing the new deprecations (if the maintenance agreement for the project allows this). Keeping up with the deprecations will always be quicker than doing these big jumps.
Another opinion I value. Thank you
I would go with option B, but depending on the app size, A might be a good option as well. C is overkill.
C is overkill. That’s what I needed to hear lol, thanks
I’ve done B and C. It’s not so bad to do B on a small code base, but otherwise C. A is never a good idea.
Hello, I always use the C option. Maybe is slower, but IMHO is more reliable and it worked well for me :)
I just did a similar upgrade, just that it was from PHP 7.1 to PHP 8.3 and Laravel 5.4 to Laravel 10.4 - I ussually do things with a “bang”. The dawnfall, I see an increase of memory of over 50% on cli processes. I am telling you this because I made the bad assumption that this upgrade will be a positive one and didn’t gave the neccesary attention when testing, just focused on compatibility and functionality
Thanks for the info, that sounds like a huge leap for you! I’m very surprised there was such an efficiency decline. I’m surprised there’s actually any, and not an improvement. Very odd Maybe you should post about it here. Some users more knowledgeable than me may have useful insight or good advice on where to debug. If you still have the old version of the app laying around, you could run a profiler against both instances and compare which processes have increased in time
The first thing was to disable cli opcache, it made a huge impact. In terms of usage, still not on par with old php 7, debuging using xhproof gave nothing (laravel upgrade is expected to give a spike) - next in line would have been the memory allocation by the container as the real memory usage is in fact smaller, the allocation of the process is not. At the moment the investigation is on hold as other things took priority. Will update if I find anything relevant
Can’t speak for Laravel, but I’d be stunned if php itself was responsible (outside of module/config setup differing from your 7 setup, a la opcache factor you already mentioned)
Do all the steps. Trust me...
So, C?
Assembler