rfc:minor-version-compatibility

PHP RFC: Minor version compatibility

Introduction

This RFC aims to clarify and codify the rules regarding backward compatibility and userland API compatibility in PHP minor versions. Currently, there is no formal or widely respected policy for minor version changes, which has led to inconsistent expectations for contributors and users alike. By establishing a clear set of expectations and criteria for what constitutes an acceptable change in a minor release, this RFC seeks to improve predictability and trust in the PHP release cycle.

Several ongoing pull requests have sparked discussions around potential BC breaks, including:

Additionally, some related changes have already been merged:

Current release versioning from 2010's policy.

Major Version Number

  • x.y.z to x+1.0.0
    • Bug fixes
    • New features
    • Extensions support can be ended (moved to PECL)
    • Backward compatibility can be broken
    • API compatibility can be broken (internals and userland)
    • ABI can be broken (internals)

Minor Version Number

  • x.y.z to x.y+1.z
    • Bugfixes
    • New features
    • Extensions support can be ended (moved to PECL)
    • Backward compatibility must be kept
    • API compatibility must be kept (userland)
    • ABI and API can be broken (internals)
    • Source compatibility should be kept if possible, while breakages are allowed

Patch Version Number

  • x.y.z to x.y.z+1
    • Bug fixes and security patches only
    • Extensions support can't be removed (like move them to PECL)
    • Backward compatibility must be kept (internals and userland)
    • ABI and API compatibility must be kept (internals)

Proposal

We propose the following unification of the list and clarification of the minor version compatibility policy.

Release versioning draft

Major Version Number

  • x.y.z to x+1.0.0
    • Backward compatibility MAY be broken
    • API compatibility MAY be broken (internals and userland)
    • It MAY include minor and patch level changes.

Minor Version Number

  • x.y.z to x.y+1.0
    • New feature MAY be added
    • Extension support MAY be ended (moved to PECL)
    • General backward compatibility SHOULD be kept with the exemptions:
      • ABI and API MAY be broken (internals)
      • Source compatibility SHOULD be kept if possible
      • If API (userland) input validation is changed to reject values previously accepted, a deprecation warning MUST be emitted in the same minor version, and a ValueError MUST be thrown in the next major version.
    • It MAY include patch level changes.

Patch Version Number

  • x.y.z to x.y.z+1
    • Bug fixes and security patches
    • Backward compatibility MUST be kept (internals and userland)

Backward Incompatible Changes

This proposal does not introduce any immediate backward-incompatible changes. Instead, it introduces a policy for how backward-incompatible changes must be introduced in a phased and transparent manner in future minor releases.

Proposed PHP Version(s)

The changes will apply immediately to the whole PHP release cycle.

Proposed Voting Choices

Primary Vote: Changes to the Release Policy for BC Versioning

The primary vote defines the general rules for backward compatibility (BC) in API versioning. A two-thirds majority (2/3) is required for this vote to pass.

Do you approve changes to the release policy regarding BC versioning
Real name Yes No
Final result: 0 0
This poll has been closed.

Secondary Vote #1: Policy for Input Validation BC Breaks

This vote defines the rules for how BC breaks in API input validation should be handled.

If accepted:

If API (userland) input validation is changed to reject values previously accepted, a deprecation warning MUST be emitted in the same minor version, and a ValueError MUST be thrown in the next minor or major version.

If rejected:

If API (userland) input validation is changed to reject values that were previously accepted, a ValueError MAY be raised in the same version.

Do you approve requiring a deprecation/warning before raising an exception?
Real name Yes No
Final result: 0 0
This poll has been closed.

Secondary Vote #2: Type of warning type used for BC breaks in API input validation

This vote applies only if the previous vote is accepted. It determines what type of warning should be emitted when input validation behavior is deprecated.

If E_DEPRECATED is chosen:

If API (userland) input validation is changed to reject values previously accepted, a E_DEPRECATED warning MUST be emitted in the same minor version, and a ValueError MUST be thrown in the next major version.

If E_WARNING is chosen:

If API (userland) input validation is changed to reject values previously accepted, an E_WARNING MUST be emitted in the same minor version, and a ValueError MUST be thrown in the next major version.

Which warning type should be used for input validation BC breaks?
Real name E_DEPRECATED E_WARNING
Final result: 0 0
This poll has been closed.

Implementation

References

rfc/minor-version-compatibility.txt · Last modified: 2025/04/27 21:30 by jorg_sowa