Hi, On Fri, May 9, 2025 at 1:09 PM Tim Düsterhus <t...@bastelstu.be> wrote:
> 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. Yeah it doesn't make much sense to note that RFC bit. I wanted to say that breaks are possible as it's already happening but the wording was not the best. > Some thoughts: > > - A minor version MUST NOT break syntax compatibility (i.e. every PHP > program that compiles must continue to compile). > Added this one > - Breaking changes in minor versions SHOULD be limited to extensions / > the API of functions within an extension. > I'm not sure about this wording but it's better than it was before so used that as well. > - 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). > So this would probably require the full definition of BC break and list this as part of it. It might need more point though. I will think about it and try to integrate it somehow. > - 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. > Another point for the BC break definition I think. Kind regards, Jakub
