Req #79759 [NEW]: Impossible to use PHP 7.3 and 7.4 together and smoothly migrate between them

From: Date: Mon, 29 Jun 2020 20:02:55 +0000
Subject: Req #79759 [NEW]: Impossible to use PHP 7.3 and 7.4 together and smoothly migrate between them
Groups: php.bugs 
Request: Send a blank email to php-bugs+get-227732@lists.php.net to get a copy of this message
From: upyx dot 00 at gmail dot com Operating system: any PHP version: 7.4.7 Package: *General Issues Bug Type: Feature/Change Request Bug description:Impossible to use PHP 7.3 and 7.4 together and smoothly migrate between them Description: ------------ Hello! In PHP 7.4 serialization mechanism has been changed in a backward-incompatible way. So it is (sometimes) not possible to serialize data in PHP 7.4 and deserialize them in PHP 7.3. The serialization is widely used to storing data in sessions, transfer data through message brokers, etc. Our site works on many servers, and the business has got to work 24/7. So we cannot upgrade all nodes at once. When we upgrade some node to PHP 7.4, it becomes to produce serialized data to a network that unsupported by other nodes. So we cannot update the nodes one by one. We've stuck here. I've asked the community how they upgraded, and a lot of them answered some like "through pain and disgrace" because they didn't expect the problem and had to solve it when they ran into it. After some investigation, we realize that the problem, not PHP itself but in the many open source libraries which declare support of PHP prior to 7.4 but use new "__serialize()/__unserialize()" methods. However, there is a problem, and we need a way to solve it. It is hardly possible to downgrade libraries because of the complicated dependency graph between them. It is barely possible to convince libraries' authors to make necessary changes because of the number of them. I propose two variants: a) backport "new" deserialization (but not serialization) to the next PHP 7.3 minor version; b) add an option to force "legacy" serialization to the next PHP 7.4 minor release. The first variant is the easiest to use. The second variant is the easiest to implement. By the way, we solved *our* problem with migration. It took a while, so I want to help others. -- Edit bug report at https://bugs.php.net/bug.php?id=79759&edit=1 -- Fix committed: https://bugs.php.net/fix.php?id=79759&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=79759&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=79759&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=79759&r=needscript Try newer version: https://bugs.php.net/fix.php?id=79759&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=79759&r=support Expected behavior: https://bugs.php.net/fix.php?id=79759&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=79759&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=79759&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=79759&r=globals PHP version support discontinued: https://bugs.php.net/fix.php?id=79759&r=phptooold Daylight Savings: https://bugs.php.net/fix.php?id=79759&r=dst IIS Stability: https://bugs.php.net/fix.php?id=79759&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=79759&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=79759&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=79759&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=79759&r=mysqlcfg

« previous php.bugs (#227732) next »