Hi
Am 2025-05-09 12:47, schrieb Jakub Zelenka:
I'd like to start discussion for some release process updates defined
in
the following RFC / linked PR:
RFC: https://wiki.php.net/rfc/policy-release-process-update
Policy PR: https://github.com/php/policies/pull/19
Thank you. The changes seem to accurately reflect the current practice
and make sense to me. I however noticed that “Major” and “Minor”
versions both effectively have the same allowances. Perhaps we could add
some additional nuance as to what breaking changes are allowed to be
approved by an RFC in a minor version, since breaking changes in majors
should also require an RFC. Some thoughts:
- A minor version MUST NOT break syntax compatibility (i.e. every PHP
program that compiles must continue to compile).
- Breaking changes in minor versions SHOULD be limited to extensions /
the API of functions within an extension.
- The addition of deprecations themselves is not considered a breaking
change (to resolve the discussion that comes up for each and every
bulk-deprecation RFC, when you convert Deprecations into Exceptions
that's on you).
- The addition of new symbols (e.g. functions or classes) might conflict
with user-defined classes, but this is not considered a breaking change.
An RFC should make a best effort to minimize the impact of a new
function name by choosing among equally good names (but not
unnecessarily choose a worse name, just because it is less likely to
break). This is already implied by it being legal to add features
without an RFC, but would be good to spell out explicitly.
Best regards
Tim Düsterhus
