PHP 8.6 is the next minor release in the PHP 8 series, coming right after PHP 8.5. Like every PHP version, each change in it was first written up as a public proposal, discussed in the open and voted on before it shipped.
This guide follows that path from start to finish. You'll see how an idea becomes part of PHP through the RFC process, how to sort a long changelog into what matters for your code, and how to upgrade to PHP 8.6 calmly instead of discovering problems in your production logs.
- PHP 8.6 is a minor release that follows 8.5, on PHP's roughly yearly rhythm.
- Every meaningful change starts as an RFC that is discussed in public and needs a two-thirds vote to pass.
- Sort release notes into new features, deprecations and backward-incompatible changes, and read the breaks first.
- Upgrade on a separate branch, run your full test suite and fix deprecation notices one at a time.
- Your upgrade date depends on your framework, CMS, extensions and host all supporting PHP 8.6.
- 0:00Intro
- 0:34One upgrade, a weekend of surprises
- 1:25PHP 8.6: the next step after 8.5
- 2:20Why PHP changes every year
- 3:03Every change starts as an RFC
- 3:54From proposal to vote
- 4:48Sort the changelog into three buckets
- 5:39A deprecation notice, fixed
- 6:26Upgrade on a branch, not live
- 7:19Fix notices one at a time
- 8:05Everyone upgrades on their own schedule
- 8:47Three mistakes that break upgrades
- 9:41What to remember about PHP 8.6
- 10:09Read, test, then upgrade on your timeline
Why PHP upgrades cause surprises
Upgrading PHP often feels like routine maintenance, right up until it isn't. A familiar story: everything worked fine on Friday, your host switched the PHP version over the weekend, and on Monday the logs are full of warnings and one plugin has stopped loading entirely.
Most of this pain doesn't come from bad code. It comes from changes nobody on the team read about before they went live. A function starts warning, or an old pattern is retired. Each shift is small on its own, but together they can stop a request in its tracks.
The good news is that none of these changes are secret. Every change in PHP is written down and discussed publicly months before release. The surprises are optional, as long as you know where to look and give yourself time to test.
What is PHP 8.6?
PHP 8.6 is the next step in a line you have probably already been following: PHP 8.0, 8.1, 8.2, 8.3, 8.4, 8.5 and now 8.6. Each release builds on the one before it. Think of it as one more step on a staircase you're already climbing, not a brand new building.
Calling it a minor release doesn't mean it's unimportant. The word describes where it sits in PHP's version numbering. It stays inside the PHP 8 family, and large, sweeping breaks are saved for a major version. Even so, a minor release can still include small backward-incompatible changes, so it deserves a careful read.
Because a new minor version arrives roughly once a year, PHP 8.6 is part of a predictable schedule. That predictability is useful: you can plan upgrade work into your year instead of reacting to it when a host flips a switch.
- Minor release in the PHP 8 series, after 8.5
- Sweeping breaks are reserved for major versions
- Small backward-incompatible changes are still possible
- New minor versions arrive about once a year
Why does PHP release a new version every year?
A language that millions of developers use every day has to keep up with how they actually work. Each yearly release balances adding new things with cleaning up old ones, and it usually does three jobs at once.
First, it brings new features that make code shorter or safer. Second, it ships fixes for pain points developers kept tripping over. Third, it marks behavior that is outdated or confusing as retired, so it can be removed later in an orderly way.
The reason for doing this in small steps is practical. Spreading change across yearly releases keeps each upgrade manageable, instead of forcing one huge rewrite every decade. Seen this way, PHP 8.6 is one step forward, not a cliff.
What is a PHP RFC?
Nobody simply commits a new language feature to PHP on a whim. Every meaningful change begins as a written proposal called an RFC, short for Request For Comments. It's a request for a change, put in front of the community, with the goal of gathering feedback before anything is decided.
An RFC is a document with a clear structure. It explains the problem, the proposed design, code examples and, importantly, what existing code might break. That last section is especially valuable when you upgrade later, because it tells you exactly where to look in your own codebase.
RFCs are a public record. They live on the PHP wiki at wiki.php.net, alongside links to the discussion and the final vote result. This is the single most useful thing to know about PHP releases: nothing arrives unannounced, and you can read the reasoning behind every change yourself.
How does an RFC get accepted into PHP?
An RFC's life is a back-and-forth between its author and the core developers, held in public on the PHP internals mailing list where anyone can follow along. The author posts the proposal, feedback comes back with questions and objections, and the author revises the RFC to answer them.
When the proposal is ready, a vote opens. To be accepted, an RFC needs at least two-thirds of the votes in favor. That high bar stops PHP from swinging back and forth on every new idea, and it means changes need broad agreement rather than a narrow win.
Some RFCs fail, and that's healthy. A declined RFC never reaches a release. The process is deliberately slow so that problems surface in discussion rather than in your production logs, and anything that appears in the final release notes has already survived public scrutiny.
- RFC posted by the author
- Feedback from core developers and the community
- RFC revised to address concerns
- Vote opens; two-thirds yes is required to pass
How to read the PHP 8.6 changelog
Once a release is out, all the accepted RFCs land in one long changelog. The trick is not reading it top to bottom, but sorting every line into one of three buckets: new features, deprecations and backward-incompatible (BC) changes. Once sorted, a long list becomes a short list of things that actually affect you.
New features add syntax or functions and don't break anything, because you opt in to them. Deprecations make old behavior emit a warning but still run. BC breaks change behavior, and they can make code fail. That's why you start with the breaks: they decide whether your code runs on PHP 8.6 at all. Features come last; adopt them gradually once the upgrade is stable.
A real example shows how deprecations work. PHP 8.4 deprecated implicitly nullable parameters. A function written as f(User $u = null) still ran, but produced a deprecation notice saying the parameter is implicitly nullable. The fix is to mark it explicitly as ?User $u = null; run again and the notice is gone. The same pattern applies to whatever PHP 8.6 deprecates: read the notice, make a small fix, confirm it's gone.
- New features: opt-in, don't break code
- Deprecations: old behavior warns but still works
- BC breaks: changed behavior that can fail
- Read BC breaks first, features last
How to upgrade to PHP 8.6 safely
The safe path has three moves: a separate branch, your full test suite, and a careful look at what it reports. You're not trying to be clever; you're trying to make every problem show up somewhere safe. Create an upgrade branch, confirm with php -v that you're really running 8.6, then run your tests.
In the example below, the tests pass, but PHPUnit reports issues, including deprecations to look at. Treat those as your to-do list for the upgrade, not background noise to silence. Branching first means production keeps running the old version, and you can throw the branch away if things go wrong.
Then fix the notices in a short loop: run the tests, read one notice to find the exact file and line, fix only that one, and commit it with a clear message. Repeat until none remain. Small commits are easy to review, and if one fix causes trouble you revert just that commit. A suite with zero deprecation notices is ready for 8.6 and already prepared for the next release.
- Branch first so production stays untouched
- Run the whole test suite, not just a few pages
- Note every deprecation notice
- Fix one notice per commit until the suite runs clean
git checkout -b php-8.6-upgrade
php -v
vendor/bin/phpunitWhen can you actually upgrade to PHP 8.6?
A PHP release doesn't reach your app the moment it appears on php.net. It travels through an ecosystem of projects and companies, each moving at its own pace. Frameworks such as Laravel and Symfony test the new version and declare support. CMS platforms such as WordPress and Drupal do the same, and hosting providers decide when to offer it.
Your app needs every one of those layers to be ready. Before you pick a date, check each piece you depend on, whether that's a framework, a plugin, an extension or your host. Your upgrade can only move as fast as the slowest piece in that chain.
Common mistakes that break PHP upgrades
Most failed upgrades come from skipped steps, not hard problems. The first mistake is upgrading production first. Changing the live server before testing on a branch or staging copy means your users find the bugs. Always test somewhere disposable before touching anything real.
The second mistake is ignoring deprecations. Silencing notices feels tidy, but today's warning becomes a hard error in a future version, usually when you're in a hurry. The third is forgetting extensions. Compiled extensions such as Xdebug or Redis need builds for the new PHP version; check each one first, or features you rely on may simply disappear.
- Upgrading production before testing anywhere else
- Silencing deprecation notices instead of fixing them
- Not checking that compiled extensions support 8.6
Key takeaways
- PHP 8.6 follows 8.5 as part of a roughly yearly release rhythm.
- Every change starts as a public RFC on wiki.php.net and needs a two-thirds vote.
- Sort release notes into features, deprecations and BC breaks, reading breaks first.
- Upgrade on a branch and let your full test suite show what changed.
- Fix deprecation notices one at a time, with one small commit each.
- Check frameworks, CMS, extensions and hosting before choosing an upgrade date.
Frequently asked questions
Is PHP 8.6 a major or minor release?
PHP 8.6 is a minor release in the PHP 8 series, following PHP 8.5. Large, sweeping breaks are reserved for major versions, but a minor release can still include small backward-incompatible changes, so read the release notes before upgrading.
What does RFC mean in PHP?
RFC stands for Request For Comments. It's a written proposal describing a problem, the proposed design, code examples and the impact on existing code, published on wiki.php.net for public discussion before a vote.
How many votes does a PHP RFC need to pass?
An RFC needs at least two-thirds of the votes in favor to be accepted. This supermajority keeps PHP from changing direction on every new idea, and RFCs that are declined never reach a release.
Will deprecation notices break my code?
Not immediately. Deprecated code still runs; the notice is an advance warning that a future version will stop accepting it. Fixing deprecations now prevents them from becoming hard errors later.
What should I check before upgrading to PHP 8.6?
Read the backward-incompatible changes first, then confirm your framework, CMS, plugins, compiled extensions and host support 8.6. After that, test the upgrade on a separate branch with your full test suite.
Where can I read about upcoming PHP changes?
Proposals are published as RFCs on the PHP wiki at wiki.php.net, with links to the discussion and vote results. The discussion itself happens publicly on the PHP internals mailing list.
