PHP 8.6 Release Date: GA Set for 19 November After Final RC5, What Developers Should Test

Somewhere in a Bhopal co-working space, a developer is staring at a staging server and a wall calendar. The official PHP 8.6 release date is Thursday, 19 November 2026, and the final release candidate, RC5, is scheduled for 5 November. That leaves two weeks for agencies, plugin authors and Laravel teams to run their tests, catch breakage in logins and checkouts, and decide when production should move.

When we checked php.net on 4 November, the newest 8.6 build listed was RC4 from 21 October. If you are reading this on 5 November, look for the RC5 post in the php.net news archive before assuming it is out.

PHP 8.6 release date: 19 November, with RC5 as the last stop

PHP 8.6.0 is scheduled for general availability on Thursday, 19 November 2026, according to the timetable that the release managers maintain on the PHP wiki. Before that comes RC5, pencilled in for Thursday, 5 November. The RC4 post on php.net spelled out the plan: the next build would be "the last release candidate (RC5), planned for 5 November 2026".

Why stop at five? A release candidate is a dress rehearsal. The script is frozen and only fixes for stage accidents are allowed. Hard feature freeze for 8.6 arrived on 22 September, so nothing new can slip in now. RC5 buys one more fortnight of testing; if no blocker appears, GA follows from the same branch.

So is PHP 8.6 stable today? Not for a live shop. Release candidates are feature complete but still carry the label "do not use in production" on php.net. The wiki also warns that individual releases may be added or removed as work progresses, which means the PHP 8.6 release date is a firm plan rather than a promise.

Releases are tagged on a Tuesday and published on the Thursday, so any GA delay usually surfaces in that gap.

From Alpha 1 to GA: how the PHP 8.6 calendar unfolded

The full PHP 8.6 cycle runs about twenty weeks, from Alpha 1 on 2 July 2026 to the PHP 8.6 release date of 19 November 2026. Here is the timetable as published on wiki.php.net, with the actual RC4 date from php.net:

• Alpha 1: 2 July, Alpha 2: 16 July, Alpha 3: 30 July
• RFCs targeting 8.6 merged by 11 August
• Beta 1 and soft feature freeze: 13 August
• Beta 2: 27 August, Beta 3: 10 September
• Hard feature freeze: 22 September
• RC2: 24 September (RC1 skipped)
• RC3: 8 October, RC4: 21 October
• RC5: 5 November, GA: 19 November

The release candidate that was never shipped

RC1 did not reach php.net as an official release. The RC2 announcement on 24 September opened with a line that reads like a wink: "It is not a typo". A mistake was made while packaging RC1, so the team released RC2 instead and linked a blog post with the full explanation. Linuxcompatible.org reported that RC1 had been tagged on 22 September, with RC2 following about 18 hours later. The fair wording, then, is that RC1 was skipped as a public release, not that it never existed.

The numbering left a quirk. Because RC1 never shipped, the public count runs one behind the labels: RC2 was the first candidate users could download, and php.net describes RC4 as the third. RC4, for its part, landed on 21 October, a day earlier than the RC3 post had said, shipping alongside urgent security releases.

Why RC4 mattered: patches for two remote code execution flaws

RC4 carried the fixes for two critical vulnerabilities that can allow unauthenticated remote code execution, tracked as CVE-2026-109618 and CVE-2026-109619. On 21 October 2026 the PHP team also patched every supported branch, from 8.2.35 at the old end up to 8.5.12, with 8.3.36 and 8.4.27 in between.

According to the php.net advisory, CVE-2026-109618 involves out-of-memory corruption and CVE-2026-109619 involves stale global state. The advisory was blunt: there are no complete mitigations, and updating is the only safe choice. That sentence deserves more attention than any new feature in 8.6.

On 23 October, php.net said it would publish a full advisory for CVE-2026-115560 with the next release and recommended setting session.upload_progress.enabled to 0 until then. On 26 October, updated Windows builds (8.5.12-1, 8.4.27-1, 8.3.36-1 and 8.2.35-1) bundled Brotli 1.2.1 to fix CVE-2026-111497, an out-of-bounds write in Brotli decompression.

Before you worry about 8.6, confirm that your live server runs the patched release of whatever branch it uses. Security details change quickly, so check the official advisories on php.net and ask your hosting provider or a qualified professional if you are unsure whether you are exposed.

PHP 8.6 new features list with examples

PHP 8.6 is a comfort release, not a speed headline, and its best additions shorten everyday code. Here are the main ones, drawn from implemented RFCs on wiki.php.net and write-ups on Laravel News and stitcher.io.

PHP 8.6 partial function application explained

Partial function application lets you call a function with some arguments filled in and get back a closure that waits for the rest. A question mark stands in for one missing argument, and three dots stand in for all the remaining ones. Write $makeSlug = str_replace(' ', '-', ?); and then $makeSlug('Hello World') returns "Hello-World". It pairs neatly with the PHP 8.5 pipe operator, which expects single-argument callables, so arrow-function boilerplate disappears.

clamp() and the smaller additions

The new clamp() function keeps a value inside a range. clamp(101, min: 0, max: 100) returns 100, clamp(-1, min: 0, max: 100) returns 0, and it throws a ValueError if min is greater than max. Other additions worth a look:

• Time\Duration, a readonly class for nanosecond-precision durations with arithmetic and comparison
• Readonly property defaults, so a readonly property can declare its value inline
• Io\Poll, a polling API over epoll, kqueue and WSAPoll, with no built-in event loop
• The SortDirection enum, with Ascending and Descending cases
• StreamError objects and an error_mode context option for stream failures
• Follow-ups to the URI extension, including builder classes

PHP 8.6 deprecations and breaking changes, starting with sessions

The changes most likely to bite sit in session handling, not in syntax. Under the Secure Session Configuration Defaults RFC, three settings change: session.use_strict_mode goes from 0 to 1, session.cookie_httponly goes from 0 to 1, and session.cookie_samesite moves from unset to Lax. Laravel News describes these as new default values, so a server whose php.ini already sets these keys keeps its own values, while fresh installs and new containers pick up the change.

When sizing up the PHP 8.6 session cookie default changes impact, look first at login and checkout flows. Strict mode rejects session IDs the server did not create. HttpOnly hides the session cookie from JavaScript. SameSite=Lax stops the cookie travelling on cross-site POST requests, so a customer who returns from a payment page through a POST callback may suddenly look logged out. Test that path first.

If a payment flow truly needs the cookie on a cross-site POST, the UPGRADING notes say to set SameSite to None and switch on session.cookie_secure.

The rest are deprecations, which raise notices rather than stop your code. The UPGRADING file in the php-src 8.6 branch lists returning from a finally block, returning values from __construct() and __destruct(), using "let" or "is" as a name and naming a function "readonly". The aliases is_double(), is_integer(), is_long() and doubleval() are deprecated too, with is_float(), is_int() and floatval() as the replacements, along with strcoll() and spl_object_hash(). Recheck that file at GA.

How to install PHP 8.6 RC on Ubuntu without touching production

Keep it far from your live server: use a spare VM, a laptop or a container. A release candidate on production is like test-driving a car on the day of your wedding procession; it might go well, but why risk it?

Ubuntu developers usually reach for the Ondřej Surý PPA (ppa:ondrej/php), which packages many PHP versions side by side; check that php8.6 packages are published there first, because pre-release availability varies. The fallback is the source tarball listed on php.net's release candidates page: download it, verify the checksum, then run ./configure, make and make test on a throwaway machine.

Run PHP 8.6 RC in Docker for testing

The quickest route is to run PHP 8.6 RC in Docker for testing. The official Docker image on Docker Hub carries an 8.6-rc tag, so a command such as docker run --rm -v "$PWD":/app -w /app php:8.6-rc php -v gives you a clean interpreter in seconds, with nothing left behind on the host. Mount the project, run the tests, discard the container.

Before trusting the results, run php -m and compare the extension list with production. Sodium (built on libsodium), intl, gd and database drivers are the usual gaps, and each may need an extra install step inside the image.

Putting the RC into CI, static analysis and bug reports

The cleanest way to test against PHP 8.6 is to add it to your continuous integration as an extra lane, not a replacement. In a GitHub Actions matrix, list 8.4, 8.5 and 8.6 side by side, run the 8.6 job inside the php:8.6-rc container, and mark it allowed to fail until GA.

Composer may refuse to install if a dependency's constraints do not yet mention 8.6. In CI only, composer install --ignore-platform-req=php lets the job proceed so you can see real failures instead of resolver errors. Then run PHPUnit with error_reporting set to E_ALL, so deprecation notices show up as warnings in the log rather than vanishing silently.

Static analysis tools that catch problems early

PHPStan can analyse your code against a target PHP version, and Rector can rewrite deprecated patterns automatically, such as swapping is_double() for is_float(). Rule sets for a new version can trail the release, so check changelogs.

Reporting a bug you find in a release candidate

If 8.6 breaks something that works on 8.5, report it. Open an issue on the php-src GitHub repository with the RC number, your operating system and the smallest script that reproduces the problem. Security bugs go through the private security reporting route instead, never a public issue.

Test Laravel app on PHP 8.6 release candidate, then turn to WordPress

Laravel teams can test with little risk, because Laravel manages its own session cookies and is largely insulated from the new native session defaults. When you test a Laravel app on PHP 8.6 release candidate builds, the danger sits in the vendor folder: older packages that call deprecated aliases, return values from constructors or lean on native session_start(). Run php artisan test inside the 8.6 container, exercise queues and scheduled jobs, and watch the log for deprecation notices. We found no official Laravel statement on 8.6 support as of 4 November.

Is WordPress compatible with PHP 8.6 yet?

Not confirmed yet. The WordPress core team's May 2026 clarification said WordPress 6.9 and 7.0 fully support PHP 8.5, with 8.3 as the recommended minimum, and did not mention 8.6. WordPress core usually publishes compatibility notes after a PHP GA.

Plugin and theme authors are where breakage tends to hide. Cart and membership plugins that call session_start() should be retested with the new SameSite and strict mode defaults. Search for is_double and similar aliases, and test checkout, login and forms in an 8.6 container before users find the bugs.

PHP 8.5 vs PHP 8.6: when to switch, and what support looks like

For most production sites, the PHP 8.6 release date is the wrong day to switch. Anyone asking "PHP 8.5 vs PHP 8.6 should I upgrade" gets a short reply: test now, then move after the first one or two point releases. PHP 8.5 is in active support until 31 December 2027 and receives security fixes until 31 December 2029, so nobody on a patched 8.5 is in a hurry.

How long will PHP 8.6 be supported? php.net gives every branch two years of active support and two further years of security fixes. On that pattern, 8.6 would get active support to the end of 2028 and security fixes to the end of 2030; php.net will publish official dates after GA.

The urgency lies elsewhere. PHP 8.2 reaches the end of security support on 31 December 2026, and 8.4 leaves active support the same day. A site on 8.2 needs a plan this quarter, and 8.5 is the sensible landing spot today.

When will hosting providers support PHP 8.6 in India?

There is no fixed date, and no Indian host we checked had announced one. Managed and VPS providers often add a new version within weeks of GA; shared hosting tends to follow control panel vendors, which can take longer. Ask your host directly rather than guessing.

A pre-launch checklist for Indian teams before 19 November

The fortnight before the PHP 8.6 release date is enough to find most problems if you start this week and test the flows that earn money:

1. Confirm production runs a patched build from 21 October or later (8.2.35, 8.3.36, 8.4.27, 8.5.12 or newer).
2. Pull the php:8.6-rc Docker image or build RC5 on a spare machine.
3. Match extensions with production using php -m.
4. Add an allowed-to-fail 8.6 lane to CI and run the full test suite.
5. Test login, logout, password reset and payment return flows against the new session defaults.
6. Run PHPStan and Rector to list deprecated calls, then fix them in your own code first.
7. Check each plugin or package changelog for 8.6 notes.
8. Write down a rollback step before any server switch.

Questions a business owner should ask the developer

Ask four things: which PHP version runs the site today, whether it received the October security patch, which features could break on 8.6, and when the team plans to move. If maintenance has slipped, a structured website maintenance and support plan keeps versions and patches on a schedule, and our web development news section will track the GA release. For primary dates, the php.net 2026 news archive remains the source to trust.

Frequently asked questions