Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130325
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
Subject: Re: [PHP-DEV] [RFC] php-community: a faster-moving, community-driven
 PHP.
Date: Sun, 15 Mar 2026 12:11:57 +0100
References: <839153A0-004D-4562-BD6E-65923201EDAA@gmail.com>
 <299760A8-5C8A-41AD-B2EB-986079D41A47@rwec.co.uk>
To: internals@lists.php.net
In-Reply-To: <299760A8-5C8A-41AD-B2EB-986079D41A47@rwec.co.uk>
Message-ID: <4E9B666B-6EC5-48ED-849E-3E23F2041FF7@cschneid.com>
From: cschneid@cschneid.com (Christian Schneider)

Am 15.03.2026 um 11:33 schrieb Rowan Tommins [IMSoP] =
<imsop.php@rwec.co.uk>:
>> A feature is eligible for removal only if both of the following =
conditions are met:
>> -  It has no active maintainer listed in the accepted community RFC =
design document.
>> -  Adoption is negligible, as evidenced by Packagist statistics.
>=20
> This feels incompatible with the rest of the process. If features are =
easy to propose, release, and iterate, it should be just as easy to mark =
them abandoned or obsolete. Otherwise, an interesting but flawed feature =
has to be maintained forever even if its author loses interest - and who =
is going to do that maintenance?
>=20
> If the intention of these features is to be experimental, perhaps =
every feature version could have a fixed lifetime. Users know that they =
can't rely on it long-term, but if it's popular it will hopefully make =
it into a stable release of PHP.

I was thinking along the same lines but it also made me wonder: Who =
would target such an unstable community version for production?
I know that I'd think more than twice before relying on any feature =
which might disappear or change again soon(ish).

>> php-community will always be based on the latest stable PHP release
>=20
> Who will be responsible for merging changes made to "feature =
extensions" back to master, and stabilising the first community release =
after a new stable release?

What about the other way around: It is assumed that the extension =
maintainers fix conflicts with changes in the stable php release, right?
As an extension maintainer and hence responsible I'd be worried about =
this, especially as changes to stable could be completely incompatible =
with my extension. Which could hurt users of my extension and therefore =
myself.

Regards,
- Chris