Hi internals,
I am posting this to announce the start of the voting process of the RFC 'Add form feed as a whitespace character in trim, ltrim and rtrim'
Wiki page: https://wiki.php.net/rfc/trim_form_feed
discussion thread: https://news-web.php.net/php.internals/129706
date to end: 2026/2/6 15:30:00 UTC
Thank you in advance for your participation.
Cheers,
Weilin Du
Hi internals,
I am posting this to announce the start of the voting process of the RFC 'Add form feed as a whitespace character in trim, ltrim and rtrim'
Wiki page: https://wiki.php.net/rfc/trim_form_feed
discussion thread: https://news-web.php.net/php.internals/129706
date to end: 2026/2/6 15:30:00 UTCThank you in advance for your participation.
It shows "PHP 8.5" as target version in the RFC. That's not possible, as it had already been released.
cheers
Derick
Oops my bad, I didn't realize the new version is released. I am convinced by Ben that the feature should be in 9.0 since this is technically a BC break.
Hmmm, so in this case I am not that sure whether I should directly reopen the vote or put in 'under discussion' again and been through another cool down period.
Cheers,
Weilin Du
----- Original Message -----
From: "Derick Rethans" derick@php.net
To: LamentXU lamentxu@163.com, "internals@lists.php.net" internals@lists.php.net
Sent: Thu, 22 Jan 2026 15:37:35 +0000
Subject: Re: [PHP-DEV] [Vote] Add form feed as a whitespace character in trim, ltrim and rtrim
Hi internals,
I am posting this to announce the start of the voting process of the RFC 'Add form feed as a whitespace character in trim, ltrim and rtrim'
Wiki page: https://wiki.php.net/rfc/trim_form_feed
discussion thread: https://news-web.php.net/php.internals/129706
date to end: 2026/2/6 15:30:00 UTCThank you in advance for your participation.
It shows "PHP 8.5" as target version in the RFC. That's not possible, as it had already been released.
cheers
Derick
Just got the newest email. I will reset the vote again and change the version to 9.0. Thank you.
Cheers,
Weilin Du
Hi internals,
I am posting this to announce the start of the voting process of the RFC 'Add form feed as a whitespace character in trim, ltrim and rtrim'
Wiki page: https://wiki.php.net/rfc/trim_form_feed
discussion thread: https://news-web.php.net/php.internals/129706
date to end: 2026/2/6 15:30:00 UTCThank you in advance for your participation.
Cheers,
Weilin Du
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.
Cheers,
Ben
Hi internals,
I am posting this to announce the start of the voting process of the
RFC 'Add form feed as a whitespace character in trim, ltrim and rtrim'Wiki page: https://wiki.php.net/rfc/trim_form_feed
discussion thread: https://news-web.php.net/php.internals/129706
date to end: 2026/2/6 15:30:00 UTCThank you in advance for your participation.
Cheers,
Weilin DuI'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.Cheers,
Ben
It looks like you changed the proposed PHP version from 8.6 to 8.5 on
the same day you opened voting.[^1] IMO, this was at least a minor
change (according to our Feature Proposals policy), which requires
notifying the mailing list of the change and should have triggered a
7-day cool down before voting could begin.[^2]
I appreciate the work you've put into this, and I agree with the need
for this change, but I'm a little worried those who voted "yes" might
not have noticed the proposed version change on the RFC from PHP 8.6 to
PHP 8.5.
Cheers,
Ben
Hi
Am 2026-01-30 01:51, schrieb Ben Ramsey:
It looks like you changed the proposed PHP version from 8.6 to 8.5 on
the same day you opened voting.[^1] IMO, this was at least a minor
change (according to our Feature Proposals policy), which requires
notifying the mailing list of the change and should have triggered a
7-day cool down before voting could begin.[^2]I appreciate the work you've put into this, and I agree with the need
for this change, but I'm a little worried those who voted "yes" might
not have noticed the proposed version change on the RFC from PHP 8.6 to
PHP 8.5.
From a policy PoV this is interesting, because the incorrect version was
noticed fairly quickly, but it was not noticed that the RFC recently
changed. When that was noticed, the 7-day window to cancel the vote
already expired, meaning there are now two conflicting policy
violations. But since this issue was pointed out early on, I ultimately
agree with the canceling of the vote.
Best regards
Tim Düsterhus
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 oftrim(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
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-numberWhile 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 oftrim(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
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-numberWhile 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 oftrim(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üsterhusWith 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
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.
PHP does not follow SemVer.
Minor BC breaks are accepted via our policy.
And as Tim said, waiting multiple years for a consistency fix (which frankly in my opinion this is more a bug fix) is completely ludicrous.
But as usual none of this would be a problem if we didn't bundle 14 000 extensions and the standard library being so massive and shoved into a single extension.
As then, the core language and extension APIs could evolve at different paces, and thus following SemVer would at least be a potential consideration.
Best regards,
Gina P. Banyard
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.
That claim is completely unsubstantiated, doesn't reflect my
experienced and researched reality, and feels quite off-topic, given
PHP very much allows for this.
--
Volker Dusch
Head of Engineering
Tideways GmbH
Königswinterer Str. 116
53227 Bonn
https://tideways.io/imprint
Sitz der Gesellschaft: Bonn
Geschäftsführer: Benjamin Außenhofer (geb. Eberlei)
Registergericht: Amtsgericht Bonn, HRB 22127
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.
That claim is completely unsubstantiated, doesn't reflect my
experienced and researched reality, and feels quite off-topic, given
PHP very much allows for this.
Citation:
https://24daysindecember.net/2022/12/06/evolving-php/
Nikita's proposal for "Editions":
https://externals.io/message/106453#106454
Ask Juliette or MWOP how much the "minor" BC breaks cause them issues.
I have responded to these issues myself in the past as well, defending PHP's approach:
https://www.garfieldtech.com/blog/upgrading-php-upgrades
But when we can ensure that upgrades are smooth and uneventful, we should.
--Larry Garfield
Nikita's proposal for "Editions":
https://externals.io/message/106453#106454
Nikita's edition proposal explicitly moved out of scope library changes, which ext/standard is. [1]
But when we can ensure that upgrades are smooth and uneventful, we should.
Every single minor release, we implement bug fixes that we deem too disruptive to do in a stable branch.
Sometimes due to behavioural changes, which I will reiterate this very much feels like a bug fix to me.
Moreover, in the current state of the project it is extremely unreasonable to demand that any minor thing be pushed back who knows how many years.
We didn't even properly handle removing all deprecation in PHP 8.0 and so have been carrying these deprecations for another 5 years.
You could not expect from the core team to spend a year + just converting resources to opaque objects, that's why it was done in stages in multiple minor releases.
(and once again this wouldn't have been an issue if those extensions didn't live in the php-src repo and weren't tied to PHP's release process.)
And we have lost multiple contributors to core because they were explicitly told the thing they were working on they should have submitted 5-6 years earlier or should wait until PHP 9.
Forcing everything to wait until the next major is a sure fire way of demotivating new people from working on the language.
Recently, discussion about fixing minor things in PHP seem to always get sidetracked by people who are not actively involved in the maintenance of PHP questioning every single decision even if those processes have been established for years.
Sometimes those are undocumented, but event after clarifying some, there is still constant questioning.
This makes working on PHP a chore and wastes a lot of people's time (and money) re-iterating existing practice, while holding the evolution of the language back.
Given how we discuss these things these days, I don't think I would have started to contribute to PHP if I started getting involved in 2025.
Best regards,
Gina P. Banyard
Ask Juliette or MWOP how much the "minor" BC breaks cause them issues.
From what I'm seeing, having to support property hooks and pipes as
valid syntax was more of a ""BC"" impact for PHP 8.x than all bug
fixes we shipped since 8.0.0 combined.
PHP has rules on what can go into a release to make this predictable,
and it's clear for tool authors what we consider BC and what not.
But when we can ensure that upgrades are smooth and uneventful, we should.
We do. I don't think your presentation of how PHP is developed and
evolves is helping discuss this, imho, absolutely compliant and
sensible RFC (might not even needed to be an RFC, but that's off-topic
as well).
I'd rather not have this policy discussion again in 2026, but either
way, this is the wrong place.
Regards,
Volker
--
Volker Dusch
Head of Engineering
Tideways GmbH
Königswinterer Str. 116
53227 Bonn
https://tideways.io/imprint
Sitz der Gesellschaft: Bonn
Geschäftsführer: Benjamin Außenhofer (geb. Eberlei)
Registergericht: Amtsgericht Bonn, HRB 22127
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.
That claim is completely unsubstantiated, doesn't reflect my
experienced and researched reality, and feels quite off-topic, given
PHP very much allows for this.
Ask Juliette or MWOP how much the "minor" BC breaks cause them issues.
My ears were burning. And yes, "minor" BC breaks can definitely be
hugely problematic, however, the "BC-break" proposed in this RFC - to me
- is not one in that category. Feels more like a bug-fix.
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.
That claim is completely unsubstantiated, doesn't reflect my
experienced and researched reality, and feels quite off-topic, given
PHP very much allows for this.
Ask Juliette or MWOP how much the "minor" BC breaks cause them issues.
My ears were burning. And yes, "minor" BC breaks can definitely be hugely problematic, however, the "BC-break" proposed in this RFC - to me - is not one in that category. Feels more like a bug-fix.
This is what I've been thinking all along, this is a bug fix.
I wasn't quite sure whether this was considered as anything else, and think a lot of time was wasted in this process. Process can be good when it is appropriate, but that line wasn't reached for this bug fix in my opinion.
cheers
Derick
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.Cheers,
Ben
I would urge you to reconsider. Pushing all bug fixes with extremely
minor BC implications into a single release that happens every 5-7
years will create problems with adoption.
This fix should, imho, very clearly go into 8.6.
Every minor ships with a BC list. E.g.
https://www.php.net/manual/en/migration85.incompatible.php and there
is nothing I can think of that is more minor than this change (maybe
except adding deprecations).
Kind regards,
Volker
--
Volker Dusch
Head of Engineering
Tideways GmbH
Königswinterer Str. 116
53227 Bonn
https://tideways.io/imprint
Sitz der Gesellschaft: Bonn
Geschäftsführer: Benjamin Außenhofer (geb. Eberlei)
Registergericht: Amtsgericht Bonn, HRB 22127
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.Cheers,
BenI would urge you to reconsider. Pushing all bug fixes with extremely
minor BC implications into a single release that happens every 5-7
years will create problems with adoption.This fix should, imho, very clearly go into 8.6.
Every minor ships with a BC list. E.g.
https://www.php.net/manual/en/migration85.incompatible.php and there
is nothing I can think of that is more minor than this change (maybe
except adding deprecations).Kind regards,
Volker
FWIW, I didn't call for the voting to be stopped. I pointed out the RFC
was changed on the day voting began to target PHP 8.5 (from 8.6) without
notifying the list, and I was worried those who voted might not have
noticed the change.
Cheers,
Ben