3 ms·

I have a question to the PHP-in-production crowd: how long do you wait before migrating to higher version of PHP? Is the first release usually already fine, or

I have a question to the PHP-in-production crowd: how long do you wait before migrating to higher version of PHP? Is the first release usually already fine, or is it better to wait for a few months and let someone else catch the early errors?

Dachande663 2y ago
The last few point releases have been very stable, so normally within a week or so. Obviously this relies on having a pretty good test suite (we run ~8,000 tests in ~60 seconds so not too bad for us).
TimWolla 2y ago
For PHP 8.3, we upgraded production during the RC phase, but were prepared to revert back to an older one by not relying on the new functionality. Docker makes this easy. As long as you do not use the new functionality, I'd claim that a new PHP version is no less stable than an older one. And on a contrary you would be missing out on some bugfixes that were deemed too risky to apply to an existing version. Disclosure: I've got a commit-bit for PHP, so we had in-house expertise to diagnose issues ourselves.
deleted 2y ago
[deleted]
edhelas 2y ago
Basically I follow Debian Stable releases and migrate all my code to it when a new version is pushed. So so far I'm on 8.2. It also often fit with the current Laravel version (11).
DaiPlusPlus 2y ago
> how long do you wait before migrating to higher version of PHP? I still have a PHP5 project that somehow still runs.
bawolff 2y ago
Wikipedia is still on php 7.4.33 so don't feel too bad if you are behind.
- inglor_cz 2y ago
  8.2 and 8.3, respectively. I enjoy the PHP 8 new features such as named arguments, constructor arguments promotion and nullsafe operators. Made my new code a lot more readable. I am not that sure about 8.4 yet, though the new array_ functions and new DOM look interesting.
- Cthulhu_ 2y ago
  For a project like Wikipedia, stability and continuity are far more important than latest and greatest feature support; in fact, there's an argument to be made to avoid newer language features to ensure consistency, that is, if new features are used, they should be used everywhere at once. Else you end up with frankenstein code where every file could use a different style.
  - inglor_cz 2y ago
    "Else you end up with frankenstein code where every file could use a different style." Yeah, this is a huge problem, but also, in the long run, inevitable. Plenty of Kernighan & Ritchie C code still out there...
    - wbl 2y ago
      Almost none: ANSI was over 30 years ago and enough of an improvement people switched. If you mean C89 then yes, loads of it.
      - skissane 2y ago
        It helps there are automated tools for converting old style K&R function declarations to the new ANSI/ISO style, like protoize. But K&R C is now so dated, protoize was removed from GCC 4.5 and onwards. When (in a bout of idiosyncrasy) I wanted to convert some ancient K&R C to new style a couple of years back, I ended up putting GCC 4.4 in a Docker container to make it easier: https://github.com/skissane/protoize https://github.com/skissane/protoize
jspaetzel 2y ago
I usually wait 6mo to a year in order for composer dependencies I use to get updated. Then its usually a trivial upgrade. I've upgraded sooner before for simpler projects though and things are usually pretty stable upon release.
dubcanada 2y ago
I wait one version, I’ll upgrade to 8.3 now and 8.4 when 8.5 is out.
pilif 2y ago
We start making sure our application runs on the next version around the time Beta 1 comes out. We upgrade the development environment around the time when our tooling (phpstan, cs-fixer) runs on the next version, but doesn't necessarily support new language features. We upgrade the production environment when our tooling supports most of the new language features and at least all of the ones we want to make use of. This usually happens within 3-6 months of the release. By that time the version has stabilized enough to be safe for production use.
kugelblitz 2y ago
Solo Dev on my own PHP project since 14 years. I wait 1-3 months, but then update. It used to take way longer, because Amazon's Elastic Beanstalk platform would take longer to update, but I've now changed to Platform.sh and the transition should be easier. It has been very backward-compatible (i.e. stuff that works in 8.n also works in 8.n+1; and unless you use exotic functions or are relying on special functionality, it should work for you, too). Once I'm at 8.4, I would slowly update the code / syntax with rector and the assistance of phpstan. For framework updates I wait 1-2 patch versions before updating, because of composer dependency problems and sometimes bugs do still find themselves into new releases (e.g. I would wait at least until Symfony 7.2.1 before upgrading from Symfony 7.1.x).
stronglikedan 2y ago
I wait until I need a new feature, or if there's a security issue. I still have PHP 5 apps in production.
- crowcroft 2y ago
  Didn't PHP 5 stop getting security updates more six or seven years ago? I guess depending on the app that might not really matter, but that seems like it could be an issue at some point.
  - giraffe_lady 2y ago
    There's an entire ecosystem of companies doing support and proprietary security patches and even framework-bearing polyfills for php 5. So much of the web runs on php 5 that is never ever going to be updated. It's a mini-industry unto itself. The licensing is on the order of thousands or low tens of thousands per year. Worth it for a 40-person business that has a 20-year-old legacy codebase supporting a few million dollars a year revenue. It's not what we think of as a standard "tech" company but it describes an absolutely ridiculous number of businesses.
artificialLimbs 2y ago
We’re still on 7.4 at my mid co. =|
eamann 2y ago
I'm just waiting for the official PHP Docker images to bump their updates ... which should be any time now.
ransom1538 2y ago
We leave it on staging for about 4 months, scan logs etc. If there is no complaints from qa or devs we roll it out.
gog 2y ago
Usually the release is fine, but dependencies can be lacking in proper support/testing of the newer versions, so it takes a couple of months. Also external tooling, like for example NewRelic extension, takes some time to release a version that supports the new release.

Dachande663 2y ago

The last few point releases have been very stable, so normally within a week or so. Obviously this relies on having a pretty good test suite (we run ~8,000 tests in ~60 seconds so not too bad for us).

TimWolla 2y ago

For PHP 8.3, we upgraded production during the RC phase, but were prepared to revert back to an older one by not relying on the new functionality. Docker makes this easy. As long as you do not use the new functionality, I'd claim that a new PHP version is no less stable than an older one. And on a contrary you would be missing out on some bugfixes that were deemed too risky to apply to an existing version. Disclosure: I've got a commit-bit for PHP, so we had in-house expertise to diagnose issues ourselves.

deleted 2y ago

[deleted]

edhelas 2y ago

Basically I follow Debian Stable releases and migrate all my code to it when a new version is pushed. So so far I'm on 8.2. It also often fit with the current Laravel version (11).

DaiPlusPlus 2y ago

> how long do you wait before migrating to higher version of PHP? I still have a PHP5 project that somehow still runs.

bawolff 2y ago

Wikipedia is still on php 7.4.33 so don't feel too bad if you are behind.

inglor_cz 2y ago
8.2 and 8.3, respectively. I enjoy the PHP 8 new features such as named arguments, constructor arguments promotion and nullsafe operators. Made my new code a lot more readable. I am not that sure about 8.4 yet, though the new array_ functions and new DOM look interesting.
Cthulhu_ 2y ago
For a project like Wikipedia, stability and continuity are far more important than latest and greatest feature support; in fact, there's an argument to be made to avoid newer language features to ensure consistency, that is, if new features are used, they should be used everywhere at once. Else you end up with frankenstein code where every file could use a different style.
- inglor_cz 2y ago
  "Else you end up with frankenstein code where every file could use a different style." Yeah, this is a huge problem, but also, in the long run, inevitable. Plenty of Kernighan & Ritchie C code still out there...
  - wbl 2y ago
    Almost none: ANSI was over 30 years ago and enough of an improvement people switched. If you mean C89 then yes, loads of it.
    - skissane 2y ago
      It helps there are automated tools for converting old style K&R function declarations to the new ANSI/ISO style, like protoize. But K&R C is now so dated, protoize was removed from GCC 4.5 and onwards. When (in a bout of idiosyncrasy) I wanted to convert some ancient K&R C to new style a couple of years back, I ended up putting GCC 4.4 in a Docker container to make it easier: https://github.com/skissane/protoize https://github.com/skissane/protoize

jspaetzel 2y ago

I usually wait 6mo to a year in order for composer dependencies I use to get updated. Then its usually a trivial upgrade. I've upgraded sooner before for simpler projects though and things are usually pretty stable upon release.

dubcanada 2y ago

I wait one version, I’ll upgrade to 8.3 now and 8.4 when 8.5 is out.

pilif 2y ago

We start making sure our application runs on the next version around the time Beta 1 comes out. We upgrade the development environment around the time when our tooling (phpstan, cs-fixer) runs on the next version, but doesn't necessarily support new language features. We upgrade the production environment when our tooling supports most of the new language features and at least all of the ones we want to make use of. This usually happens within 3-6 months of the release. By that time the version has stabilized enough to be safe for production use.

kugelblitz 2y ago

Solo Dev on my own PHP project since 14 years. I wait 1-3 months, but then update. It used to take way longer, because Amazon's Elastic Beanstalk platform would take longer to update, but I've now changed to Platform.sh and the transition should be easier. It has been very backward-compatible (i.e. stuff that works in 8.n also works in 8.n+1; and unless you use exotic functions or are relying on special functionality, it should work for you, too). Once I'm at 8.4, I would slowly update the code / syntax with rector and the assistance of phpstan. For framework updates I wait 1-2 patch versions before updating, because of composer dependency problems and sometimes bugs do still find themselves into new releases (e.g. I would wait at least until Symfony 7.2.1 before upgrading from Symfony 7.1.x).

stronglikedan 2y ago

I wait until I need a new feature, or if there's a security issue. I still have PHP 5 apps in production.

crowcroft 2y ago
Didn't PHP 5 stop getting security updates more six or seven years ago? I guess depending on the app that might not really matter, but that seems like it could be an issue at some point.
- giraffe_lady 2y ago
  There's an entire ecosystem of companies doing support and proprietary security patches and even framework-bearing polyfills for php 5. So much of the web runs on php 5 that is never ever going to be updated. It's a mini-industry unto itself. The licensing is on the order of thousands or low tens of thousands per year. Worth it for a 40-person business that has a 20-year-old legacy codebase supporting a few million dollars a year revenue. It's not what we think of as a standard "tech" company but it describes an absolutely ridiculous number of businesses.

artificialLimbs 2y ago

We’re still on 7.4 at my mid co. =|

eamann 2y ago

I'm just waiting for the official PHP Docker images to bump their updates ... which should be any time now.

ransom1538 2y ago

We leave it on staging for about 4 months, scan logs etc. If there is no complaints from qa or devs we roll it out.

gog 2y ago

Usually the release is fine, but dependencies can be lacking in proper support/testing of the newer versions, so it takes a couple of months. Also external tooling, like for example NewRelic extension, takes some time to release a version that supports the new release.