PHP 8.6 RC5 gives application teams a rehearsal window

PHP published 8.6.0 RC5 on November 5, 2026. The release team asks people to test it outside production and lists November 19 as the target for the first stable 8.6 release. For an application team, the gap between those dates is a chance to find out how the candidate behaves with the extensions, worker processes and inputs the application actually uses. [1] [2]

A healthy page load only tests one path

The RC5 change notes include fixes for cloned cURL handles, including how the clone handles a logging stream or callback data. They also describe a fix in DOM when changing an attribute whose child still has a live object representing it. That is more specific than testing whether a page renders. The affected paths are the ones that copy request handles or keep references to pieces of a document while changing it. [3]

PHP-FPM, which manages worker processes for PHP web requests, has RC5 fixes in worker output logging and in the handling of output pipes when a child process outlives its worker. A test that only runs PHP from the command line never reaches that FPM process behavior. Teams that serve requests through FPM can use the candidate in their usual test setup to look at logs and worker behavior as well as page responses. [3] [5]

Consider a hypothetical shipping portal that builds XML manifests and sends them to a carrier. A status page can look healthy even if a document edit or a request retry fails later. A realistic rehearsal would make a manifest, change it as the application usually does and send it to a test endpoint. A test with a failed response can reveal whether the worker records enough detail for someone to see where the handoff stopped.

Read the upgrade notes alongside the candidate changes

The RC5 change notes say what was fixed in this candidate. The 8.6 upgrade notes cover the wider transition. For example, they say PHP raises a ValueError when a cURL upload callback returns an integer outside its allowed control values. They also describe a change to some reads of a PHP magic property. When the check for the property's existence has already populated it, a null fallback or emptiness check can use that value directly without calling the getter again. [3] [4]

These are details that matter to particular code. A library that relies on a getter to record an event may see different behavior when the value is already available. An uploader with unusual return handling may encounter an exception at a point its error handling has never exercised. The upgrade notes give a team a way to decide which of its dependencies and paths merit a closer look. [4]

Keep a useful record of the rehearsal

Our suggestion for a release team is to compare the same small set of representative workflows on its current supported runtime and on RC5. Keep the candidate version, the worker type, the relevant extensions and a concrete example of any changed result. A report that says a carrier handoff failed after an upload callback returned an unexpected value is easier to investigate than a report that says shipping stopped working. [1] [3] [4] [6]

The PHP announcement links to the release notes and the project's bug report form. If a difference looks like a runtime issue, a small reproduction with synthetic data makes it easier to describe without sharing client records or configuration. If it belongs to a dependency or to application code, the same evidence helps identify who needs to act before a production upgrade. [1] [4]

Record whether each difference comes from a fix in RC5 or a broader change in the 8.6 branch. That gives the team a useful comparison when it repeats the rehearsal against the stable release. Keep security updates for the supported production branch on their own schedule while candidate testing runs in parallel.

The candidate gives teams an early answer about specific parts of their application. The shipping team in the example might find that manifest generation and uploads work as expected, but worker logs still need a closer look. That finding belongs in its stable release decision alongside the version and the tests that produced it. [1] [2]