Re: [RFC] php-community: a faster-moving, community-driven PHP.
| From: | Christian Schneider | Date: | Sat, 14 Mar 2026 22:59:38 +0000 |
| Subject: | Re: [RFC] php-community: a faster-moving, community-driven PHP. | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-130314@lists.php.net to get a copy of this message | ||
Am 14.03.2026 um 19:32 schrieb Daniil Gentili <daniil.gentili@gmail.com>:
> Submitting for discussion the php-community RFC, for a faster-moving, community-driven PHP:
> https://wiki.php.net/rfc/php-community
>
> With this proposal, the entire PHP community gets immediate access to experimental features
> through an official php-community version of PHP, versioned in a rolling manner (i.e. php-community
> 2026.03.01), and available on php.net along normal PHP releases.
My understanding is that
a) this creates a fork of PHP in the sense that a separate version has to be maintained
b) you assume the same core developers will be in charge of the what I call "stable" and
the "community" version of PHP
Is that correct?
This makes me worried about the additional burden on the core maintainers as well as compatibility
issues for package maintainers ("this library is only guaranteed to work with
php-community-yyyy1-mm1-dd1 to php-community-yyyy2-mm2-dd2 but not the base php" or vice
versa).
Another thing I am a bit confused about is the inclusion of sandboxing as part of this RFC: Is this
really an integral part of the community version? And while we're at it: As long as the
community version allows for PECL/PIE/whatever extensions then the sandboxing could be broken by
those extensions, so this can lead to a false sense of security / needs auditing of all extensions
included in a version. That's why I'm wary of including it as a secondary feature, it
feels a bit tacked on to me for a security topic.
Regards,
- Chris