Skip to content
Draft
Changes from all commits
Commits
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
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 patch release, and are
the main contact in case of questions regarding to and issues with the PHP
version they are responsible for. 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.

Hands-on release managers of an actively supported PHP version (i.e. the first
two years after the GA release) MUST NOT apply to be a hands-on release manager
for the upcoming PHP version. Hands-off release managers of an actively
supported PHP version SHOULD NOT apply to be a hands-off release manager for the
upcoming PHP version.

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 (application period starting in 2026).

The hands-off release manager MUST be a veteran release manager, meaning they
MUST have previously served as a hands-on release manager. The hands-off release
manager SHOULD be a hands-on release manager of a currently supported PHP
version to ensure they are familiar with the current practices. It is customary
that a hands-on release manager of the most recent PHP version volunteers as the
hands-off release manager for the upcoming PHP version.

About four months prior to the scheduled release of the first alpha release of
the upcoming PHP 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 one
of the hands-on release managers of the most recent 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 of the upcoming PHP 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

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

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