11
myss
153d

Finally finished the longest ticket I've ever worked on in my life. The ticket title and description was a pretty simple and straightforward one: "Upgrade from PHP 7.4 to 8".

If it was only so simple in real life. Our application is mostly done with API Platform framework, which is based on top of Symfony framework which is based on top of PHP language.

Once I did PHP 7 => 8 upgrade I needed to upgrade API Platform 2 => 3. But of-course that couldn't have been done as before that I needed to upgrade from Symfony 5 => 6.

This all was literally an equivalent of touching into a wasp nest - it took me a bit over 5 months and 800 hours of work and there was literally not a single source file left untouched.

In the process of all of this I've ran into literally dozen undocumented feature-breaking changes, broken backwards-compatibility promises and inside out architectural changes - from both the frameworks and the language itself.

Upgrading just one major version of anything SHOULD NOT be so hard. And to top it all up just to think I will need to do this again in a year or two..

Experiences like these really set my hate for time-based model of releases and the state of today's development in general.

Comments
  • 3
    Good work nonetheless.
  • 3
    The upgrade from 7.* to 8 was a biggie.

    It was more complex than 5.* to 7.

    While it is a pain in the arse, they've essentially ripped out all the very outdated and long-deprecated functions that should no longer be used in any project. It's a good thing in the long-run, v8 has vastly improved PHP and from this point on there should be much less breakable changes when upgrading.
  • 1
    8.1 just went out of active support so you might wanna look at starting the 8.2 upgrade (much less has changed)
  • 1
    Congrats on the upgrade I did this one too. Was a biggy. Thankfully it wasn't as involved for us as yours seems
  • 2
    Yeah... I totally get that... but my current one is totally my own damn fault.

    I currently procrastinating a few more minutes until my alarm tells me I really need to stop this time.

    I have a container(on RHEL9 local server) with some static IPv4s and Cpanel. Over a year ago, I was so exhausted from battling some bs, practically undocumented dnsmasq config file throwing off my otherwise, pristine and manually written, networking... Only with containers -.-. So I just went with a friendly, well-known, CentOS7 image... despite EOL... did a bunch of other crap under the crap rationale of 'I'm gonna need to reconfigure it all, when changing off CentOS anyways'... like letting it use it's small amount of ROM off a big drive that I need to format for dbs/etc...

    Now I've had it in the back of my mind for over a year... so basically, I don't wanna!... but it's my fault && I'm also, unfortunately, the boss. *sigh*
  • 1
    That's what major version is for however I have a suspicion that this is actually a php 5 codebase with just a few fixes to make it work with PHP 7 (and now PHP 8) with zero attention to deprecation notices and copy paste work from outdated sources.

    Symphony in particular makes it when you go to the latest version of a major version and have all notices cleared the only change to the next major version is a cleanup of the deprecated API's

    https://symfony.com/doc/current/...

    So yeah you are right, it should not be that hard... Congrats on making it work!

    My advice would be to use this ticket as leverage to fix deprecated stuff and add checks to the deployment process.
Add Comment