On Tue, Nov 4, 2025 at 2:34 PM Jakub Zelenka <[email protected]> wrote:
> On Tue, Nov 4, 2025 at 2:23 PM Tim Düsterhus <[email protected]> wrote: > >> Hi >> >> Am 2025-11-02 13:38, schrieb Jakub Zelenka: >> > Just wanted to give heads up that I plan to open voting tomorrow. >> >> I'm seeing there were some additional comments on the GitHub PR: >> >> https://github.com/php/policies/pull/19#pullrequestreview-3413485445 >> >> As I had noted on the PR before >> (https://github.com/php/policies/pull/19#discussion_r2425684839) PRs are >> a terrible medium of discussion. And especially when the list is not >> actively kept in loop, folks will inevitably miss out on some of the >> discussion. That's why I mostly refused to discuss my policy RFCs on >> GitHub, instead asking folks to come to the mailing list - which is the >> accepted official discussion medium of RFCs - to have everything in a >> single location. >> >> I appreciate that you provided plenty of heads up for folks to review >> the text after the initial (long) GitHub discussion, but after your >> announcement from https://news-web.php.net/php.internals/128819 I would >> kindly request that the ongoing discussion is kept on the list so that >> everyone has a chance to see it. > > > I think GH is good to shape the initial policy as it's easier to comment > on specific parts there but agree that the main discussion should happen on > the list once announced. But you need to ask the ones that are commenting > there. I was just replaying... > > To bring the discussion back here, there were two concerns: 1. That `Internal API compatibility breaks are NOT RECOMMENDED.` is not the current practice. I always thought that it is our current practice to limit the internal API breaks to minimum so we don't in general don't recommend those. But if others disagree that it's our current practice, I'm happy to remove it. Personally I think it's good to have such recommendation because internal API breaks often delay the release usage if some important extension does not get updated. We had a very good example in imagick. 2. The already existing rule RM can "Decide which bug fixes can be applied to a release, within the cases defined in this RFC" was questioned if it should stay and if RM ever used it. I think it should stay because it's good to have some rule about who can decide a potential disagreement whether the bug should be merged to the specific branch. This part has been already in policy so there's not much to do here. Kind regards, Jakub
