PHP's release process rules date back to 2010 and say a minor release, like 8.4 to 8.5, must keep backward compatibility. But nobody agreed on what that means in practice, and some pull requests sparked arguments about whether they broke too much. This RFC from Jorg Sowa tried to write down clear rules for what a minor release can and can't change.

What it proposed

The RFC rewrote the release rules using the MUST, SHOULD and MAY keywords:

  • Major versions (like 8.x to 9.0) MAY break backward compatibility and userland APIs.
  • Minor versions (like 8.5 to 8.6) MAY add features and move extensions to PECL. They SHOULD keep backward compatibility, though PHP's internal C API MAY still break.
  • Patch versions (like 8.5.1 to 8.5.2) are for bug and security fixes only, and they MUST keep backward compatibility.

The biggest new rule covered input validation. If a function starts rejecting a value it used to accept, PHP would first have to emit a deprecation warning in a minor release, and the actual ValueError would only come later.

Two secondary votes were planned:

  • Whether to require that warning before throwing at all. If not, a ValueError could arrive right away.
  • Which warning level to use, E_DEPRECATED or E_WARNING.

The changes would have gone into PHP's release process policy document.

What it means for you

Nothing changes, since the RFC was withdrawn. It never touched any code and would only have set rules for future releases.

Where it stands

The author withdrew the RFC. The page is at version 0.9, dated April 13, 2025. Vote polls were set up, but no votes were cast.