Re: [RFC] php-community: a faster-moving, community-driven PHP.

From: 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

« previous php.internals (#130314) next »