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.