Hi Am 2026-05-03 16:14, schrieb Eric Norris:
- I wasn't sure how to approach the merger of the two topics. I decided to model this like the various deprecation RFCs, in that we're deciding on a slate of minimum supported software for PHP 8.6.
Yes, that makes sense to me.
- Ideally, if people objected to the MySQL minimum version for persistent connections, I'd be able to include a vote that allowed for an INI setting.
This would effectively be two competing RFCs and that could work with our voting policy. One possible issue is that folks might be biased against voting for the upgrade if there is the INI escape hatch. I really don't like the extra maintenance effort (e.g. duplicate code paths that no one is going to test) of the INI. I generally think an opinionated RFC by a subject matter expert (i.e. you :-)) is stronger than one that leaves every decision up to the voters.
- Related to that: I'm not sure how much detail to add about the actual implementation I'd like for persistent connections. Is this a vote for my specific implementation, or just the higher-level concept of requiring a certain version of software in PHP 8.6? My goal is to ship this, so needing to do two RFCs back-to-back would be annoying.
IMO it should be a vote for the increased minimum version with a good argument as to why this increased minimum version is useful, specifically “more predictable behavior for persistent connections, because any per-connection state can cleanly be reset” and “support for C11 in autotools, which already is the documented minimum in https://github.com/php/php-src/blob/8d0777e88b8494807727fc57c148c2497976eff5/CODING_STANDARDS.md?plain=1#L12, but folks will only notice if compilation fails halfway through”.
Best regards Tim Düsterhus
