Every PHP branch has a fixed support window, published on php.net. Knowing those dates turns PHP upgrades from emergencies into routine maintenance. This page collects the dates for every supported branch as of 31 October 2026, explains what each support phase means, and suggests a simple way to plan.
The supported branches
| Branch | Initial release | Active support until | Security fixes until | Latest release (Oct 2026) |
|---|---|---|---|---|
| 8.2 | 8 Dec 2022 | 31 Dec 2024 | 31 Dec 2026 | 8.2.35 |
| 8.3 | 23 Nov 2023 | 31 Dec 2025 | 31 Dec 2027 | 8.3.36 |
| 8.4 | 21 Nov 2024 | 31 Dec 2026 | 31 Dec 2028 | 8.4.27 |
| 8.5 | 20 Nov 2025 | 31 Dec 2027 | 31 Dec 2029 | 8.5.12 |
Recently ended branches, from php.net's list of unsupported branches:
- 8.1: end of life 31 December 2025, last release 8.1.34.
- 8.0: end of life 26 November 2023, last release 8.0.30.
- 7.4: end of life 28 November 2022, last release 7.4.33.
What "active" and "security only" mean
According to php.net, each branch is fully supported for two years from its first stable release. During this active support period, reported bugs and security issues are fixed in regular point releases. After that, the branch gets two more years of security support for critical security issues only, with releases made as needed: there may be several in a year, or none. At the end of those four years the branch is end of life and receives nothing further from the PHP project.
The 2026 release history shows the difference clearly. The actively supported 8.4 and 8.5 branches had a release roughly every four weeks, eleven each between January and October. The security-only 8.2 branch had five releases in the same period, each one in a month with security fixes.
Notice also that all current branches end their support phases on 31 December. That makes year-end the natural deadline in a maintenance calendar.
Key dates, year by year
2026
- 19 November 2026 (scheduled): general availability of PHP 8.6, according to the release managers' schedule on the PHP wiki. Release candidates were being published in October; treat the date as a plan, not a promise. Its support dates will appear on php.net once it is released.
- 31 December 2026: PHP 8.2 reaches end of life. PHP 8.4 leaves active support and becomes security-only.
2027
- 31 December 2027: PHP 8.3 reaches end of life. PHP 8.5 becomes security-only.
2028
- 31 December 2028: PHP 8.4 reaches end of life.
2029
- 31 December 2029: PHP 8.5 reaches end of life.
Distribution packages follow their own clock
If you install PHP from your Linux distribution, the distribution's lifecycle matters as much as php.net's. Distributions pick one PHP branch per release and backport security fixes for the life of that release, sometimes beyond the upstream end of life.
| Release | Default PHP | Distribution support (from the vendor) |
|---|---|---|
| Debian 12 (bookworm) | 8.2 | Debian LTS until 30 June 2028 |
| Debian 13 (trixie) | 8.4 | Until 9 Aug 2028; LTS until 30 June 2030 |
| Ubuntu 22.04 LTS | 8.1 | Standard security maintenance until May 2027 |
| Ubuntu 24.04 LTS | 8.3 | Standard security maintenance until May 2029 |
| Ubuntu 26.04 LTS | 8.5 | Standard security maintenance until May 2031 |
Two practical consequences. First, a distribution-supported PHP can be patched after its upstream end of life (Ubuntu 22.04 still ships fixes for PHP 8.1, for example), but those fixes depend entirely on the distribution's security team, and your frameworks and libraries will stop supporting the old branch regardless. Second, when you upgrade the operating system you also change PHP branch, so plan both together.
How to plan upgrades
- Inventory. For each server and site, record the PHP branch, where it comes from (distribution, third-party repository, self-compiled, control panel) and the framework version.
php -v,ls /etc/php/andapt policy php8.*-fpmcover most Debian and Ubuntu systems. - Pick targets with a runway. Move to a branch with at least two years of security support left. Today that means 8.4 (to the end of 2028) or 8.5 (to the end of 2029). Moving to 8.3 now buys only fourteen months.
- Put the deadlines in the calendar. For each branch you run, add its end-of-life date, plus a reminder about three months earlier to start testing.
- Keep up with patch releases. Being on a supported branch only helps if you install its updates. Subscribe to the low-volume php-announce mailing list or the php.net news feed, and apply distribution updates regularly.
- Upgrade one branch at a time in testing. Each version has an official migration guide listing incompatible changes and deprecations. Read them in order when you skip versions.
A sustainable rhythm for most teams is to move to a new branch roughly every two years, during the branch's active support period, rather than waiting for the last weeks of security support.
What you should do
- Check today which branches you run: anything on 8.2 or older needs a plan before 31 December 2026.
- Choose 8.4 or 8.5 as the target for new upgrades.
- Record end-of-life dates for every branch and operating system you run, with a reminder three months ahead.
- If you depend on distribution packages, align PHP upgrades with operating-system upgrades.
- Follow php.net release announcements and apply patch releases as they come.
Sources
- php.net/supported-versions.php
- php.net/eol.php
- php.net/releases
- php.net/ChangeLog-8.php
- wiki.php.net/todo/php86
- php.net/mailing-lists.php
- debian.org/releases
- wiki.debian.org/LTS/Bookworm
- packages.debian.org/bookworm/php
- packages.debian.org/trixie/php
- ubuntu.com/about/release-cycle
- people.canonical.com/~ubuntu-archive/madison.cgi?package=php&text=on
- changelogs.ubuntu.com/changelogs/pool/main/p/php8.1/php8.1_8.1.2-1ubuntu2.28/changelog
Comments
0 total · 0 threads