Release Manager Selection

It passed with 17 votes in favor, 6 against and 4 abstaining, clearing the two-thirds majority it needed. Voting closed on June 1, 2026.

Every PHP version has release managers, the people who tag and ship each release. This RFC from Tim Düsterhus rewrites the rules for how they get picked. It doesn't change how things work day to day. Instead, it makes the written policy match what the project has already been doing.

Why change it#

The old policy was hard to follow. It said the team "consists of two or three people," with at least one "veteran" and the others possibly someone new. It never said who decides between two and three, or what happens if a veteran gets fewer votes than a newcomer.

In practice, the last several PHP versions all had three release managers. One was a veteran from the previous version who mostly gave advice, and the other two were new and handled the daily work. The call for volunteers often asked for exactly that split, so when more than one person could fill the veteran spot, it wasn't clear how the vote should be set up.

What the new policy says#

The new text lives in a pull request to the php/policies repository. At a high level, it says:

• Each version gets three release managers. Two are "hands-on" and do the actual release work. The third is "hands-off," giving advice and stepping in as a backup.
• No one is hands-on for two versions at once. This limit covers a version's first two years, while it's in active support.

The RFC also drops the old "alternatives" wording and uses clearer names for each role.

What it means for you#

Nothing changes in your code, since this is a rule about how the PHP project runs itself. If you'd like to be a release manager someday, the roles are now spelled out, so you know what you'd be signing up for.