Take the State of PHP 2026 Survey →

Policy release process update View as Markdown

Accepted
Authors
Jakub Zelenka, bukka@php.net
Date
2025-05-09
Version
0.3
Source
wiki.php.net/rfc/policy-release-process-update

Vote

Update the release process as proposed? closed
Yes
15
No
0
Abstain
4
19 voters
asgrim Yes 2025-12-15 07:14
bukka Yes 2025-12-02 11:10
bwoebi Yes 2025-12-02 17:18
crell Abstain 2025-12-02 19:43
dragoonis Abstain 2025-12-03 15:36
galvao Yes 2025-12-05 17:34
girgias Yes 2025-12-05 20:11
ilutov Yes 2025-12-05 18:57
kalle Yes 2025-12-02 21:28
kguest Yes 2025-12-08 12:48
mbeccati Yes 2025-12-05 16:05
ocramius Abstain 2025-12-02 13:18
patrickallaert Yes 2025-12-03 11:20
petk Yes 2025-12-06 17:36
ramsey Yes 2025-12-13 01:52
santiagolizardo Abstain 2025-12-02 11:44
sergey Yes 2025-12-02 11:24
theodorejb Yes 2025-12-02 19:31
weierophinney Yes 2025-12-14 14:43

Discussions on the mailing list

[RFC][Discussion] Policy release process update
by Jakub Zelenka · 21 messages
[VOTE] Policy release process update
by Jakub Zelenka · 2 messages

RFC text

Copied from wiki.php.net, last synchronized Oct 13, 2026 11:49 UTC

Introduction

This is a policy RFC that tries to match the current policy with the process that we currently have and also clarify few details.

Proposal

The policy change is composed of the following items

  • Add a Requirements Notation section to the README to define the use of BCP 14 / RFC 2119 and RFC 8174 keywords.
  • Replace the “From / Updated by” header with a Sources table listing the relevant RFCs.
  • Introduce a new Backward Compatibility section that:
    • Defines what constitutes a BC break and standardises related terminology (syntax, userland API, internal API, ABI).
    • Notes several situations that are not considered BC breaks (such as deprecations or fixes to undefined behaviour).
    • Clarifies documentation requirements for user-facing and internal changes.
  • Clarify the versioning rules:
    • Major versions may include BC and ABI breaks and may end SAPI or extension support.
    • Minor versions should remain backward compatible, but may end extension support; SAPI removal is not recommended. Other BC or ABI breaks may occur if justified and approved through an RFC.
    • Patch versions remain for bug and security fixes only, with a narrow exception for high-severity security issues that may require an ABI change.
  • Add a new Major Version Bump section describing the decision process and timing for introducing a new major series.
  • Extend post-GA maintenance rules to allow:
    • Build-compatibility fixes and limited crash or regression fixes during years 3 and 4 with RM approval.
  • Update the Feature Selection and Development process:
    • New features are proposed through GitHub PRs.
    • RFCs are only required if a core developer objects or requests one within a defined review period.
    • User-facing language changes still always require an RFC.
  • Adjust Release Manager responsibilities to match current practice and remove obsolete wording.

Proposed Voting Choices

Yes / No vote requiring 2/3 Yes votes to pass. Vote will end 2025-12-16T12:00:00Z.

Vote: Update the release process as proposed? — Yes: 15 · No: 0 · Abstain: 4 (closed)

Policy pull request