How does the PHP release cycle work: how often does a new minor version ship, and what support does each branch get?

## Version numbers A PHP version has three parts, `major.minor.patch`, for example **8.5.11**: - **Major** (the `8`): a new major version is where the project allows the largest backward-incompatible changes. PHP 8.0 was the last one and is the reason the 8.x line compares strings and numbers differently from 7.x. - **Minor** (the `5`): a yearly feature release. It adds language features and functions, deprecates old behaviour, and can also contain a **few documented incompatibilities**; the manual's migration guide for each minor has a "Backward Incompatible Changes" section. - **Patch** (the `11`): bug-fix and security releases on an existing branch. These do not add features. The pair `major.minor` names a **branch** (8.4, 8.5). Everything below is about the life of a branch. ## The yearly schedule The php-src release-process document fixes the calendar: | Phase | When | What happens | |---|---|---| | Alpha 1 | second Thursday of July (usually) | the pre-release cycle starts | | Alphas | about 6 weeks | at least **3 alpha** releases | | First beta | late summer | **feature freeze** for the new version | | Betas and RCs | autumn | at least **3 betas** and **4 release candidates** | | GA | late November, targeted at the **fourth Thursday** | the new `X.Y.0` is stable | | Patch releases | **every four weeks** after GA | each preceded by an RC two weeks earlier | The whole pre-release run is **20 weeks**. The calendar is a target, not a guarantee: 8.5.0 was released on 20 November 2025, a week before the fourth Thursday. Alphas, betas and RCs are called *non-stable* releases; only GA and later patch releases are *stable*. The project also publishes builds every two weeks, and release managers avoid releasing on Fridays and weekends so that downstream packagers have working days to react. ## Support phases of a branch Once a branch reaches GA it moves through three phases: 1. **Active support**: regular patch releases that fix bugs and security issues. 2. **Security-only support**: releases happen only when a security issue needs fixing. 3. **End of life (EOL)**: no more releases from the PHP project at all. The exact start and end date of each phase is published per branch on php.net's supported-versions page. The policy that sets the length of these windows has changed over the years, so the professional habit is to **look the dates up** when planning rather than recite a number from memory. An operating-system distribution may backport fixes to its own packaged PHP for longer, but that is the distribution's promise, not the PHP project's. ## Where things stand now - **8.5** is the current stable branch, and **8.5.11** (24 September 2026) is its latest patch release. - **8.6** is in its pre-release cycle and is not a production target yet. - Each earlier 8.x branch is somewhere in the active, security-only or EOL phase, which you check on php.net. ## Why interviewers ask The question checks whether a candidate treats the runtime as something that ages. Useful consequences to mention: - A new minor every November means an application that never upgrades falls **one branch further behind every year**. - Running a branch after its EOL means known vulnerabilities in the interpreter stay unpatched. - Upgrading one minor at a time is usually cheap, because each migration guide lists only the changes since the previous minor; skipping several branches piles those lists up. - Feature freeze at the first beta is why the list of an upcoming version's features is reliable from late summer on, while its behaviour can still change in bug fixes until GA. A good short answer names the yearly late-November GA, the pre-release cycle, the four-weekly patch releases and the bug-fix, security-only and EOL phases, and says where the real dates are published.