# RFC: Policy release process update

- Status: Accepted
- Authors: Jakub Zelenka, bukka@php.net
- Date: 2025-05-09
- Version: 0.3
- Original: https://wiki.php.net/rfc/policy-release-process-update
- Page: https://externals.io/rfc/policy-release-process-update
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

## Votes

### Update the release process as proposed? (closed)

Yes: 15 · No: 0 · Abstain: 4

Voters: asgrim (Yes), bukka (Yes), bwoebi (Yes), crell (Abstain), dragoonis (Abstain), galvao (Yes), girgias (Yes), ilutov (Yes), kalle (Yes), kguest (Yes), mbeccati (Yes), ocramius (Abstain), patrickallaert (Yes), petk (Yes), ramsey (Yes), santiagolizardo (Abstain), sergey (Yes), theodorejb (Yes), weierophinney (Yes)

## Discussions on the mailing list

- [\[RFC\]\[Discussion\] Policy release process update](https://externals.io/message/127328.md) — started on 2025-05-09, 21 messages
- [\[VOTE\] Policy release process update](https://externals.io/message/129505.md) — started on 2025-12-02, 2 messages

---

## 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

- <https://github.com/php/policies/pull/19>