Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130019
Date: Thu, 05 Feb 2026 17:21:36 +0000
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [Vote] Add form feed as a whitespace character in trim, ltrim and rtrim
Message-ID: <m2Jjt8P7QiTXv_M949skJPytessqt3b9KXGBHakLL2iO5HY26kAxkNHsMfITXYWEmVCbqA_-rF1-dQtFQ3xpiNfX-zDOyujKBHx8AhIK044=@gpb.moe>
In-Reply-To: <8ec76a6c-3dba-4184-955c-cc8ee679a318@app.fastmail.com>
References: <4deea2df.a2a0.19be6247b75.Coremail.lamentxu@163.com> <20260130003750.5CA2A1A00BD@lists.php.net> <886205c77a8fdf08f4ddfb28b7605e51@bastelstu.be> <20260204011605.D6E871A00BD@lists.php.net> <9310fbfc-a7bc-44df-beac-5a46d6b14f61@app.fastmail.com> <CAMzRQTcPCx+DZQAZ6Tjahzb0USGtqAS6=dNKjpu+9Ntx-AupDA@mail.gmail.com> <8ec76a6c-3dba-4184-955c-cc8ee679a318@app.fastmail.com>
Feedback-ID: 96993444:user:proton
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Thursday, 5 February 2026 at 16:04, Larry Garfield <larry@garfieldtech.c=
om> wrote:

> Nikita's proposal for "Editions":
> https://externals.io/message/106453#106454

Nikita's edition proposal explicitly moved out of scope library changes, wh=
ich 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 disrupt=
ive 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 h=
ave been carrying these deprecations for another 5 years.

You could not expect from the core team to spend a year + just converting r=
esources to opaque objects, that's why it was done in stages in multiple mi=
nor 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 explicit=
ly 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 demot=
ivating new people from working on the language.

Recently, discussion about fixing minor things in PHP seem to always get si=
detracked by people who are not actively involved in the maintenance of PHP=
 questioning every single decision even if those processes have been establ=
ished 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 mo=
ney) re-iterating existing practice, while holding the evolution of the lan=
guage back.
Given how we discuss these things these days, I don't think I would have st=
arted to contribute to PHP if I started getting involved in 2025.

Best regards,

Gina P. Banyard


[1] https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/0000-lan=
guage-evolution.md#scope-and-eligible-changes