PHP has a written policy for how releases work, covering what can change in each kind of version and how new features get in. This RFC from Jakub Zelenka updates that policy so the written rules match what the project already does in practice, and it clears up a few details along the way.
What changes
The RFC changes the policy in several ways:
- Defined terms. Words like "must" and "should" get a fixed meaning, taken from the standards that define them.
- What counts as a break. A new section defines a backward compatibility break. It also lists things that aren't breaks, such as deprecations or fixing behavior that was never defined.
- What each version can do. Major versions can break things and drop support for extensions or SAPIs (the layer that connects PHP to a web server or the command line). Minor versions should stay compatible, though they can still drop an extension, and other breaks need an RFC. Patch versions stay limited to bug and security fixes, with one narrow exception for serious security issues.
- Major version bumps. A new section explains how the project decides when to start a new major version.
- Older versions. In years 3 and 4 after a release, the release managers can approve fixes for building PHP, plus some crash and regression fixes.
- New features. New features start as pull requests on GitHub. An RFC is only needed if a core developer objects or asks for one within a set time, and changes to the language itself still always need an RFC.
- Release managers. Their duties are updated to match what they actually do.
What it means for you
Your code doesn't change, because these rules are about how PHP gets made. You'll mostly notice the effect in two places. It's now clearer what a minor version is allowed to break, and some smaller features can reach PHP through a pull request without going through a full RFC.
The vote
It passed 15 to 0, with 4 abstaining, against the two-thirds majority it needed. Voting closed on December 16, 2025.