On Tue, Feb 3, 2026, at 7:16 PM, Ben Ramsey wrote: > On 2/3/26 08:18, Tim Düsterhus wrote: >> Hi >> >> Am 2026-01-30 01:37, schrieb Ben Ramsey: >>> I've voted "no" on this RFC since the RFC says the proposed PHP >>> version is PHP 8.5, which I interpret as meaning PHP 8.6, since 8.5 >>> was released in November. >>> >>> Even if PHP 8.6 is the proposed version, I still think the target >>> version should be PHP 9.0, since this is a BC break. I mentioned my >>> concern about this being a BC break in the discussion thread. >>> >>> The RFC is also clear this is a BC break. It says: >>> >>>> This is a **backward incompatible change**. Scripts that rely on >>>> `trim()` *preserving* leading or trailing Form Feed characters will >>>> be affected. >>> >>> I'm a little surprised by the number of folks who voted "yes" on this, >>> despite it being very clear this is a BC break and PHP "Next" is the >>> implied proposed version. >> >> I however disagree that the target version of this RFC should be 9.0. >> >> It technically is a BC break, but so is almost anything else, including >> any bugfix. Our policy explicitly allows BC breaks in minor version, but >> gives some recommendations as to what BC breaks are acceptable: https:// >> github.com/php/policies/blob/6ff3612f7f60e9d91188d986cfb4ca84d0722732/ >> release-process.rst#minor-version-number >> >> While the proposed BC break would be a “silent” BC break, I believe it >> qualifies for the “case by case” exception, since: >> >> - It is unifying the behavior with other programming languages, >> including standards defining what “whitespace” means. >> - trim is well-understood in the community as “removing whitespace”. >> - Thus it not removing something that clearly is whitespace could be >> interpreted as a bug. >> - If users for some reason rely on form feed characters being preserved, >> I expect them to be well aware of their special requirement. >> - For those users, mitigating the break is possible with basic tooling, >> by simply searching the codebase for all occurences of `trim(` and then >> adjusting the calls to explicitly specify a list of characters to trim >> (or to replace them with a wrapper). >> >> For these reasons I don't think we should wait several years until PHP 9 >> to make the change. We're shipping more impactful breaking changes and >> bugfixes with every minor version. >> >> Best regards >> Tim Düsterhus > > > With this in mind, I'm still wary of the change, but I wouldn't vote > against it if it targets PHP 8.6. > > Cheers, > Ben
Where as I would, because we catch flack every version for how many "small" BC breaks we have. It hinders people's ability to upgrade and generates bad PR for PHP routinely. Majors exist for a reason. --Larry Garfield
