Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130331
Content-Type: text/plain;
	charset=us-ascii
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.
In-Reply-To: <4E9B666B-6EC5-48ED-849E-3E23F2041FF7@cschneid.com>
Date: Sun, 15 Mar 2026 13:22:56 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <879157D0-22BE-45AB-B200-A1A6DECF4B5C@gmail.com>
References: <839153A0-004D-4562-BD6E-65923201EDAA@gmail.com>
 <299760A8-5C8A-41AD-B2EB-986079D41A47@rwec.co.uk>
 <4E9B666B-6EC5-48ED-849E-3E23F2041FF7@cschneid.com>
To: Christian Schneider <cschneid@cschneid.com>
From: daniil.gentili@gmail.com (Daniil Gentili)



>>> 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.
>=20
> 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).


Strict removal conditions and bundling of multiple versions into a =
single php-community build are there precisely to allow thought-free =
adoption of feature extensions, without being afraid of suddenly losing =
access to them or encountering breaking changes.

>=20
>>> 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?
>=20
> 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.

Note, fixes to feature extensions due to breaking changes to internal =
PHP APIs will be handled by whoever is making the breaking changes, not =
by the feature owners (like with Linux).

Regards,
Daniil Gentili.=