Clarified the following points: ideally, php-community releases will come with all major versions (i.e. ^1=1.1 + ^2=2.1 + ^3=3.0, not 1.0 + 1.1 + 2.0 + 2.1 + 3.0) of all feature extensions shipped together.
Security updates are provided to all versions currently shipping in php-community releases.
Removal of old major versions happens at the discretion of feature owners, based on adoption statistics.
Hello !
Le dimanche 15 mars 2026 à 13:44, Daniil Gentili <daniil.gentili@gmail.com> a écrit :
In other words, feature extensions are "guests" allowed into the php-community branch, or PIE extensions "pre-installed" into PHP, and are developed and maintained exclusively by their owners just as if they were a standalone extension, with some overview from `php-src` maintainers, yet maintaining independence on design/API choices (again, as if they were standalone extensions).
I'm following this thread and it make me think about the current extension landscape.
Maybe I'm a bit naive here but I think that this discussion can give more room to extension development:
* Extensions are outside of the php-src and maintained by their maintainers
* Extensions can interact with PHP core without adding work for the current maintainers
* No need to distribute specific PHP versions with available features.
Also I'm afraid that if we have a lot of different features in the progress that will create a crazy possible combination matrix. How to ensure everything behave correctly with all the others, or only some of them inside the community version?
So I don't understand why we need the php-community version if it contains "only preinstalled" extensions that users can experiment themselves. Maybe it can allow verifying adoption but that means users that will switch to the community version for a daily usage and it'll split the user base.
However I think deeper features and experiments are important. I think that extension can't completely change PHP behavior today, extensions might only have access to specific part of the engine lifecycle. Maybe it can be interesting to add more hooks so extensions can leverage deeper features and changes?
I think it can simplify this RFC by having a complete separation between the engine, stable and production ready and the experiments (which can stay extensions).
With PIE it's now easier to install extensions and also test them.
This way users can install extensions, tests features. An extension become really useful it can still be merged in the core like it was done in the past (maintainers can still maintain the core part).
Thanks
Stéphane
---
Stéphane Hulard
Also I’m afraid that if we have a lot of different features in the progress that will create a crazy possible combination matrix. How to ensure everything behave correctly with all the others, or only some of them inside the community version?
In the same way projects handle different versions of libraries, through requires and conflicts declarations.
So I don’t understand why we need the php-community version if it contains “only preinstalled” extensions that users can experiment themselves. Maybe it can allow verifying adoption but that means users that will switch to the community version for a daily usage and it’ll split the user base.
However I think deeper features and experiments are important. I think that extension can’t completely change PHP behavior today, extensions might only have access to specific part of the engine lifecycle. Maybe it can be interesting to add more hooks so extensions can leverage deeper features and changes?
I think it can simplify this RFC by having a complete separation between the engine, stable and production ready and the experiments (which can stay extensions).
With PIE it’s now easier to install extensions and also test them.
This way users can install extensions, tests features. An extension become really useful it can still be merged in the core like it was done in the past (maintainers can still maintain the core part).
The point is not to setup scaffolding in PHP for feature extensions.
The point is to bundle experimental extensions into PHP (even normal PHP), in order to speed up adoption across the entire ecosystem, including shared hosts.
On 3/15/26 07:42, Daniil Gentili wrote:
Clarified the following points: ideally, php-community releases will come with all major versions (i.e. ^1=1.1 + ^2=2.1 + ^3=3.0, not 1.0 + 1.1 + 2.0 + 2.1 + 3.0) of all feature extensions shipped together.
Security updates are provided to all versions currently shipping in php-community releases.
Removal of old major versions happens at the discretion of feature owners, based on adoption statistics.
I've seen adoption statistics mentioned a number of times in this thread and a few times in the RFC, but I can't find anything that explains how these statistics will be gathered and measured. Will this be determined through community surveys? Will PHP need some kind of "phone home" functionality to gather statistics about feature usage?
Cheers,
Ben
I’ve seen adoption statistics mentioned a number of times in this thread
and a few times in the RFC, but I can’t find anything that explains how
these statistics will be gathered and measured. Will this be determined
through community surveys? Will PHP need some kind of “phone home”
functionality to gather statistics about feature usage?
The plan is to use packagist installation statistics.
On 3/15/26 09:01, Daniil Gentili wrote:
I've seen adoption statistics mentioned a number of times in this thread
and a few times in the RFC, but I can't find anything that explains how
these statistics will be gathered and measured. Will this be determined
through community surveys? Will PHP need some kind of "phone home"
functionality to gather statistics about feature usage?The plan is to use packagist installation statistics.
I know those statistics show what versions of PHP are being used, so you should be able to see what php-community versions are used, but can you gather information on which experimental features within a php-community version are actively used?
Cheers,
Ben
On Sun, Mar 15, 2026, at 15:14, Ben Ramsey wrote:
On 3/15/26 09:01, Daniil Gentili wrote:
I’ve seen adoption statistics mentioned a number of times in this thread
and a few times in the RFC, but I can’t find anything that explains how
these statistics will be gathered and measured. Will this be determined
through community surveys? Will PHP need some kind of “phone home”
functionality to gather statistics about feature usage?The plan is to use packagist installation statistics.
I know those statistics show what versions of PHP are being used, so you
should be able to see what php-community versions are used, but can you
gather information on which experimental features within a php-community
version are actively used?Cheers,
Ben
Those statistics also only show you who is using composer. There are many communities that don’t use packagist/composer at all or barely. (WordPress comes to mind immediately)
— Rob
The plan is to use packagist installation statistics.
I know those statistics show what versions of PHP are being used, so you
should be able to see what php-community versions are used, but can you
gather information on which experimental features within a php-community
version are actively used?
By treating feature extensions as packages, reporting directly their installation stats as for normal packages.
I would not be against introducing opt-in telemetry like in Go to cover cases like WordPress, but given the large adoption of Composer even just packagist would be fine to start.
On Sun, Mar 15, 2026, at 16:00, Daniil Gentili wrote:
given the large adoption of Composer even just packagist would be fine to start.
That sounds like peak selection bias. The CMSs that don’t use composer/packagist easily make up for 40+% of the web, and also stand to benefit the most from a program like this simply won’t be reflected in the stats.
— Rob
Il dom 15 mar 2026, 16:21 Rob Landers rob@bottled.codes ha scritto:
On Sun, Mar 15, 2026, at 16:00, Daniil Gentili wrote:
given the large adoption of Composer even just packagist would be fine to start.
That sounds like peak selection bias. The CMSs that don’t use composer/packagist easily make up for 40+% of the web, and also stand to benefit the most from a program like this simply won’t be reflected in the stats.
This is one of the many implementation details that will be likely be defined by a later RFC, so I would prefer if the discussion and voting focused on the overall RFC (add PhpFeatures to mainline/a fork/both PHP).
On 3/15/26 10:00, Daniil Gentili wrote:
The plan is to use packagist installation statistics.
I know those statistics show what versions of PHP are being used, so you
should be able to see what php-community versions are used, but can you
gather information on which experimental features within a php-community
version are actively used?By treating feature extensions as packages, reporting directly their
installation stats as for normal packages.
Do you mean the feature extensions would be distributed and installed using PIE?
Cheers,
Ben