Skip to content

Clarify policy for Release Manager Selection #28

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
TimWolla wants to merge 2 commits into
base: main
Choose a base branch
from
+44 −26
Draft

Clarify policy for Release Manager Selection #28

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ec9f3e0
Clarify policy for Release Manager Selection
TimWolla Mar 22, 2026
30a5552
Remove duplicate words
TimWolla Mar 28, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
70 changes: 44 additions & 26 deletions release-process.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -455,32 +455,50 @@ But they are not:
Release managers selection
****************************

About three months prior to the scheduled release of the first alpha release of
the next minor or major version (around April 1st or shortly thereafter), the
release managers for the latest version branch should issue a call for
volunteers to begin the selection process for the next release managers.

The release manager team consists of two or three people, it is notable that at
least one of the volunteers should be a "veteran" release manager, meaning they
have contributed to at least one PHP release in the past. The other can be an
additional veteran or, ideally, someone new to the RM role (to increase number
of veteran RMs).

Issue the call for volunteers on internals@lists.php.net on or around March 1st.
See, for example: https://news-web.php.net/php.internals/113334

There is no rule for how long the call for volunteers must remain open. We
should aim to select the release managers by early April, so announcing the call
in early March gives people about a month to decide whether they wish to
volunteer.

Voting is conducted using "Single Transferrable Vote" (STV).

Using some maths, we'll start with the 1st preference and gradually remove
candidates with the fewest votes, transferring votes that had previously gone to
them to their voter’s 2nd preference, and so on. Once required number of
candidates have a quorum (Droop quota), those will be officially selected as our
RMs.
The release manager team for each PHP version MUST consist of two hands-on
release managers and one hands-off release manager. Hands-on release managers
perform the actual release manager work as outlined above, in particular they
make the actual releases, usually alternating for every version, and are the
main contact in case of questions regarding to and issues with an release. The
hands-off release manager advises the hands-on release managers, helps resolve
disagreements between the hands-on release managers as a “tie-breaker” and steps
in if one of the hands-on release managers becomes unavailable.

The hands-off release manager MUST be a veteran release manager, meaning they
MUST have previously served as a release manager. The hands-off release manager
SHOULD be a hands-on release manager of a currently supported PHP version. It is
customary that a hands-on release manager of the immediately preceding PHP
version volunteers as the hands-off release manager for the following PHP
version.

Release managers MUST NOT be a hands-on release manager for more than one
actively supported PHP version (i.e. the first two years after the GA release;
including the pre-release period) at the same time. As an example, a hands-on
release manager for PHP 8.3 (actively supported until 2025-12-31) is only
eligible to be a hands-on release manager starting with PHP 8.6 (pre-release
period starting in 2026). Release managers SHOULD NOT be a hands-on release
manager for more than one PHP version at the same time (i.e. including the
security-only phase).

Release managers SHOULD NOT be a hands-off release manager for more than one
actively supported PHP version at the same time.
Copy link
Copy Markdown
Member

@derickr derickr Mar 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only exception that I can think of here, is that if a hands-on one disappears, and the hands-off one needs to take over for an extended amount of time.

Copy link
Copy Markdown
Member Author

@TimWolla TimWolla Mar 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's why I used a SHOULD here. With the current practice of current hands-on 👉 next hands-off, there should not be a situation where any RM does more than one hands-off release, but I don't think it is necessary to make this a hard blocker, since I expect it to be reasonably unlikely for a hands-on RM to disappear (particularly not in the first two years).


About four months prior to the scheduled release of the first alpha
release of the next minor or major version (early March), the process to find
release managers for the upcoming PHP version MUST start with a “call for
volunteers” on the ``internals@lists.php.net`` mailing list. The process SHOULD
be started by the hands-on release managers of the last PHP version.

The application period SHOULD last roughly one month, such that the vote for the
next release managers starts in early April, about three months prior to the
scheduled release of the first alpha version. The end of the application period
MUST be defined in the “call for volunteers” email. It MAY be extended if an
insufficient number of volunteers stepped forward.

See the call for PHP 8.6 release managers as an example:
https://news-web.php.net/php.internals/130240

Voting is conducted using "Single Transferrable Vote" (STV) method.
Copy link
Copy Markdown
Member

@derickr derickr Mar 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As Jakub indicated, I think we should include a way that if no volunteer seems to clear a "safe pair of hands" bar, then we need find another solution/person. I would in such case rather have a hands-off RM manage another release, then an unsuitable person. The trick is naturally how to set a bar for "Safe pair of hands".

Copy link
Copy Markdown
Member Author

@TimWolla TimWolla Mar 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where did Jakub indicate that? But I don't think this is a concern in practice, we have always managed to find (new) RMs that were suitable and with the limit of “at most one hands-on release”, just 6 folks would be sufficient to manage releases, while staying fully in line with the proposed policy:

  • 8.5: hands-on: A + B; hands-off: Z
  • 8.6: hands-on: C + D; hands-off: A
  • 8.7: hands-on: E + F; hands-off: C
  • 8.5 goes out of active support
  • 8.8: hands-on: A + B; hands-off: E
  • 8.6 goes out of active support
  • 8.9: hands-on: C + D; hands-off: B
  • 8.7 goes out of active support


***************************************************************
Feature(s) preview release, solving the experimental features
Expand Down
Loading