# PHP 8.6 is on the way: the language's steady evolution > Before PHP 8.6 ships: why predictable annual releases and 'boring' versions of a mature language are actually good news. - Published: 2026-11-01 - Category: Languages - Tags: PHP - Reading time: 4 min read - Source: https://muhammetsafak.com/blog/php-8-6-on-the-way-the-languages-stable-evolution/ - Language: en-US - Author: Muhammet Şafak --- PHP 8.6 is coming out in a few weeks — [on November 19, 2026](https://wiki.php.net/todo/php86), according to the release schedule. I'm writing this — as I do every year — before the release is out, working from the RFCs and the release candidate packages. I won't be giving you a full list of new features; this post isn't really about one release. It's about the **steady evolution** PHP has been quietly sustaining for years. ## A predictable cadence PHP has been shipping a minor release every year since 2020. With a single exception — 8.2, which landed on December 8, 2022 — the date has always been November, and the last three releases have all fallen between November 20 and 23. The more time passes, the more I appreciate that regularity. Knowing when a release is coming makes planning possible: teams can schedule upgrades on their calendars, library maintainers can prepare, and nobody gets caught off guard. A tempo that's reliable rather than exciting — that's the hallmark of a mature technology. A language you eagerly await every year wondering "what's coming this time?" is also a language you'd hesitate to build a decade-long project on. ## What I do before a release ships My routine before every release is the same. I read through the RFC list and look at what got accepted. I try the release candidate just enough to run the tests of a project I work on against it. I pay close attention to deprecated features. There's a detail in this schedule that is exactly what makes release day boring: **the feature list freezes in September.** For 8.6, the hard feature freeze was September 22, 2026; after that date no new feature goes into the release, only bug fixes. So there is nothing we learn in November — November only ships what was already settled in September. This year's list follows the familiar pattern. The one visible syntax addition is [partial function application (PFA)](https://wiki.php.net/rfc/partial_function_application_v2): the RFC passed 33 to 0 and its status is "Implemented". The rest is cleanup — the [8.6 deprecation list](https://wiki.php.net/rfc/deprecations_php_8_6) is a long one; returning from a `finally` block, for instance, now raises a deprecation warning (39 in favour, 3 against). The secret to evaluating a new release "as soon as it ships" is to have been following it before it ships. If release day is full of surprises, you're already behind. ## I don't rush to adopt new features The moment a language release lands, everyone gets excited about putting the new features into their code. These days, I prefer to wait. I reach for a feature when I see it solving a real problem — not because it's new. New syntax doesn't always mean better code; sometimes it just means newer code. PHP's additions over recent years — [the maturation of the type system](https://muhammetsafak.com/blog/php-85-on-the-way-the-languages-maturing-face/), [the growing support for immutability](https://muhammetsafak.com/blog/php-8-2-readonly-classes-and-new-types/) — have genuinely changed how I write code. But adopting them took months, sometimes a year. Not rushing isn't a loss; it's a filter. ## How I plan upgrades My approach to adopting a new minor release has settled into a pattern over the years. I don't move it to production the moment it ships; I give it a waiting period first. The first step is waiting for the libraries I use to become compatible with the new version. When a language release lands, the whole ecosystem isn't ready the same day — it takes a few weeks, sometimes a few months. Jumping in early and wrestling with an incompatible dependency costs more time than it saves. The second step is starting the migration with smaller projects. I move a personal or low-risk project to the new version first; if everything is fine there and the tests are green, I move on to larger projects. This sequence means I discover any surprises at the cheapest possible point. The third step is cleaning up deprecated features. Adding new features is the exciting part; but the real work is removing deprecated ones in time. Ignoring a deprecation warning is just choosing to turn it into a real error in the next major release. There is no announced timeline for PHP 9.0 — but you pay the bill for accumulated warnings on the day it arrives. ## Closing thoughts PHP 8.6's contents were frozen back in September; I know the list. What I don't know is how much room these features will take up in my own code — I can only tell you that after running the release on a real project for a few months. But there's one thing I already know: PFA aside, this is, like the ones before it, a release that doesn't transform the language dramatically — it matures it one step further. In a long-lived language, that's exactly what I'm looking for. Not spectacle, but continuity. Visual: The Evolution of PHP: From 5.5 to 8.6 (https://muhammetsafak.com/visuals/i/php-evolution-from-5-5-to-8-6/)