# [RFC] php-community: a faster-moving, community-driven PHP.
- Thread: https://externals.io/message/130313
- Original archive: https://news-web.php.net/php.internals/130313
- Started by Daniil Gentili on 2026-03-14T18:32:24+00:00
- Messages: 44
- RFC: php-community: A faster-moving, community-driven PHP (Under discussion) — https://externals.io/rfc/php-community.md
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/130313.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt
---
## #130313 — Daniil Gentili — 2026-03-14T18:32:24+00:00
URL: https://externals.io/message/130313#130313
Hello internals,
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.
As anticipated by Edmond Dantes in an earlier thread, I'm now part of the True Async committee.
I decided to not present the RFC as explicitly linked to True Async, to explicitly prevent an interpretation where it is something that will allow us to "sneak in" True Async into PHP.
True Async is one of, but not the only nor the main reason why I created this RFC.
I truly believe that PHP could really benefit from a more agile community RFC process, that can transform it from just a decent and fast language I and so many others love, to an amazing, blazing fast and actually modern and ergonomic language.
I believe PHP truly deserves this.
Kind regards,
Daniil Gentili.
—
Daniil Gentili - Senior software artisan
Website: https://daniil.it
GitHub: https://github.com/danog
Email: daniil@daniil.it
---
## #130314 — Christian Schneider — 2026-03-14T22:59:38+00:00
URL: https://externals.io/message/130313#130314 · In reply to: #130313
Am 14.03.2026 um 19:32 schrieb Daniil Gentili :
> 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
---
## #130315 — Daniil Gentili — 2026-03-14T23:59:24+00:00
URL: https://externals.io/message/130313#130315 · In reply to: #130314
>
> 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.
Yes, this is mostly correct: however note that the maintenance burden of feature extensions will lay squarely on the feature maintainers/authors, listed in the designed document of merged community RFCs.
Developers outside of the feature maintainers should only need to touch feature extension code when introducing breaking changes to extension APIs, like is already the case now for extensions.
This is actually very close to the approach used by linux: drivers are owned and maintained each by their own maintainers: non-maintainers need to touch driver code only when authoring breaking changes to inner Linux APIs which affect drivers.
> 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).
It is for precisely this reason that all feature extensions are versioned (possibly with multiple versions of a single extension shipping in a single php-community release), and full information about available versions is exposed through the PhpFeatures class, in a format matching Composer JSON repositories.
Package maintainers are expected to rely on specific versions of features (feature-performance:^2), not on specific releases of php-community.
I initially even considered not exposing the current php-community version at all to userland, exposing just the stable php version it is based on, but then decided against it as there is still a small amount of non-feature extension scaffolding code unique to php-community, which may have bugs, which may require versioning (i.e. a bug the PhpFeature class itself).
Thinking about it some more, PhpFeature and scaffolding code may itself be exposed as a versioned, always-enabled php-community feature extension, so now that I think about it, exposing the current php-community version is even more useless, but I’d still leave it exposed even if just for PR reasons.
>
> 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.
>
Sandboxing is expected to cover only features offered by mainline PHP, php-community and all extensions and feature extensions shipping with PHP and php-community, not normal extensions installed separately (though normal extensions may choose to opt-in and respect sandboxing levels as well, if they wish).
Sandboxing is indeed somewhat a separate matter from php-community, and can in fact be fully defined by a separate (community or normal) RFC. However, it is absolutely mandatory for the implementation of the main goal of php-community: fast adoption of new features by the entire PHP community, especially shared hosts, which require sandboxing by definition, and cannot be expected to look through the list of changes in all feature extensions bundled in all of the monthly releases of php-community.
In fact, IMO one of the reasons why shared hosts often lag behind PHP versions is the (small, but non-negligible) cost of searching and patching sandbox escape hatches introduced by new PHP versions, so sandboxing, if merged in mainline PHP, may also speed up adoption of even normal PHP upgrades.
Regards,
Daniil Gentili.
---
## #130316 — Ilija Tovilo — 2026-03-15T00:20:39+00:00
URL: https://externals.io/message/130313#130316 · In reply to: #130313
Hi Daniil
>
> Submitting for discussion the php-community RFC, for a faster-moving, community-driven PHP: https://wiki.php.net/rfc/php-community
I understand and appreciate your desire to accelerate the development
speed of PHP. However, this proposal would put a completely
unrealistic burden on php-src maintainers.
By design, it would become very easy to add new features to the
community branch. However, code isn't merged and forgotten; it
requires continued maintenance. Features interact, bugs need to be
fixed, code will diverge from release branches and require conflict
resolution, development of features through PRs would still require
reviews by maintainers, etc. The additional effort to keep all of this
working correctly for underspecified and questionable features would
be immense.
There's no real veto for php-src maintainers, a single internals
member can overrule the "veto" mentioned in the RFC. If a problematic
feature is accepted, it must be supported for at least 6 months,
further burden falls on php-src maintainers to propose the removal of
the problematic feature, and it might not even be removed unless:
> Adoption is negligible, as evidenced by Packagist statistics.
I honestly think this would be catastrophic.
I think this development model works much better with authoritative
working groups or a benevolent dictator, along with a coherent
roadmap. And crucially, failed ideas would be removed before this
community edition becomes a cemetery of failed ideas.
Ilija
---
## #130317 — Daniil Gentili — 2026-03-15T01:45:19+00:00
URL: https://externals.io/message/130313#130317 · In reply to: #130316
>
>
> > […]
> community-driven PHP: https://wiki.php.net/rfc/php-community
>
> I understand and appreciate your desire to accelerate the development
> speed of PHP. However, this proposal would put a completely
> unrealistic burden on php-src maintainers.
>
> By design, it would become very easy to add new features to the
> community branch. However, code isn't merged and forgotten; it
> requires continued maintenance. Features interact, bugs need to be
> fixed, code will diverge from release branches and require conflict
> resolution, development of features through PRs would still require
> reviews by maintainers, etc. The additional effort to keep all of this
> working correctly for underspecified and questionable features would
> be immense.
>
As mentioned in the RFC and earlier in the thread, the burden of
maintaining feature extensions will lay exclusively on the owners of the
community RFCs, and any other maintainers appointed by them.
Features and bug fixes for feature extensions will NOT be a responsibility
of php-src maintainers.
This also includes reviews on feature extension code, which will be a
exclusive responsibility of the owners of said features.
In other words, feature extensions are "guests" allowed into the
php-community branch, and are developed and maintained exclusively by their
owners just as if they were a standalone extension.
Of course, a more detailed review on behalf of php-src maintainers is still
preferable for the initial addition PR, but it is not required (even if
obviously still allowed) for subsequent PRs.
> There's no real veto for php-src maintainers, a single internals
> member can overrule the "veto" mentioned in the RFC.
No, that is not correct, a single internals member cannot overrule a veto
made by all remaining internals members.
Only 50%+1 internals members put together can overrule a veto made by the
remaining half.
If a problematic
> feature is accepted, it must be supported for at least 6 months,
>
By the feature owner, not php-src maintainers (again, like with Linux).
further burden falls on php-src maintainers to propose the removal of
> the problematic feature, and it might not even be removed unless:
>
> > […]
>
To be honest, this is not all too different from the current state of PHP:
there is a large amount of extension code in core which are only there
because it was added a long time ago to cover a specific usecase, and is
still there even if technology has moved on and that feature is no longer
in use by the *majority* of the PHP userbase (thinking about legacy db
drivers).
In php-community, actual, real adoption statistics will be available
through packagist, making removal actually a lot easier.
> I think this development model works much better with authoritative
> working groups or a benevolent dictator, along with a coherent
> roadmap. And crucially, failed ideas would be removed before this
> community edition becomes a cemetery of failed ideas.
>
I partially agree, and partially disagree.
Go indeed does have a few benevolent dictators that get the final words in
case the various committees cannot find an agreement: this has worked out
*mostly* well for them, but unlike processes, a benevolent dictator is not
something that can be easily copied.
I personally cannot think of a single person that can be entrusted with the
role of a benevolent dictator for PHP.
On the contrary, I believe that the current status quo of PHP is "a bunch
of dictators with largely varying opinions" is actually a good thing,
because internals members fight it out in full transparency, in a public
mailing list, presenting a variety of viewpoints and arguments.
The only missing thing, which is the main reason why I made this RFC, is
real adoption data and feedback from the community that can be used to
empower or defeat viewpoints during the public internals argument.
The definition of "failed ideas" should not be up to any single internals
member to decide, it should be up to the actual users, who actually get to
use the language every day.
Regards,
Daniil Gentili.
---
## #130322 — Edmond Dantes — 2026-03-15T09:17:57+00:00
URL: https://externals.io/message/130313#130322 · In reply to: #130316
Hello!
> However, this proposal would put a completely unrealistic burden on php-src maintainers.
It seems to me this is an organizational problem that certainly has a
good solution.
In my company we also use something similar.
In practice it does not require that much effort. Moreover, right now
I am doing essentially the same thing for the TrueAsync project:
- the php-src code is updated
- tests are run
- if the tests pass, the code proceeds further
I am doing this manually, although the process could be automated.
TrueAsync currently has about 18,000+ lines of changes in PHP-SRC.
Over these six months my personal attention was required only 2–3
times. I can confirm a similar experience with other projects as well.
A large number of different solutions can be devised here, both at the
level of flow and rules, and at the level of technical approaches. So
yes, it is a problem.
But it is a problem that has a solution.
> There's no real veto for php-src maintainers,
This question is more complex. I personally prefer the models used by
Go and Python, which rely on consensus rather than voting. I would
only add a long path of iterative development, where a feature reaches
users at an early stage. Releasing a feature early is what provides
quality guarantees, something that is well confirmed by modern IT
practice.
Building a quality product using the scheme “first we design an RFC
here → then nobody can actually implement it” has historically not
worked well. Companies spent millions of dollars on this approach in
the 1960s–70s, and the percentage of successful projects built this
way was extremely small.
This applies not only to the async project. Generics and most
moderately complex features are in the same boat.
> I honestly think this would be catastrophic.
Not impossible. Although using statistics and real-world usage to
evaluate features is definitely useful. The question is how to use it
most effectively.
I think this requires some thought.
Best regards, Ed
---
## #130323 — Rowan Tommins [IMSoP] — 2026-03-15T10:33:34+00:00
URL: https://externals.io/message/130313#130323 · In reply to: #130313
>
>Submitting for discussion the php-community RFC, for a faster-moving, community-driven PHP: https://wiki.php.net/rfc/php-community
Hi Daniil,
This sounds like a very ambitious idea, but I'm skeptical about both the work involved, and whether it will actually achieve its aim.
> For the first time, official binaries and packages will be provided for all major Linux distros for php-community releases on php.net
Who is going to create and maintain these packages? Who decides which distros, which versions, etc? Like sandboxing, this could fill an RFC on its own.
> Multiple versions of the same feature may be offered at the same time in a single php-community release
How will this work, code-wise? Are these versions actually separate implementations side by side, or limited to changes that can be represented with feature flags?
What is the minimum lifetime and lifecycle of these versions? Can a version be retired early if it has an unsolvable stability or security issue?
> internals members through GitHub 👍 = Accept, 👎 = Reject, 👀 = Abstain reactions on the issue using their GitHub accounts,
I don't think we have any suitable definition of "internals members" that can apply here. Do you mean people with commit access to the php-src repo? Or are you hoping to cross-check GitHub users against main.php.net accounts (as used by the current voting widget) somehow?
> 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.
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?
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.
> php-community will always be based on the latest stable PHP release
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?
> Community releases are “handled” by the same release managers of the latest stable PHP release, however the release process will be significantly automated, compared to the current manual release process
Is there something that makes this automation easier for community releases than regular ones? Or is automaton of the existing process something that needs to be done before we can consider this RFC?
> Wait for the CI status of the new branch to become green
If there are failing tests in a particular feature when it's time to tag a community release, what happens? Does the release get delayed until the maintainer of that feature fixes it?
> php-community will live on a new community branch of php-src
Who will be responsible for the stability of this branch? This is really important, because you're targeting this concept at shared hosts, who want to know the software they're running is stable and secure.
Why will somebody trust this branch containing a bunch of separately-maintained feature extensions any more than they would trust a repository of PIE extensions? If anything, it is far *more* dangerous, because the features aren't limited to the normal extension API.
> Note: the first community RFC may indeed be the one regarding the choice of appropriate sandbox keys.
By definition, the sandbox mechanism needs to exist outside of the feature extension system, and be stable across community versions. As others have said, it's basically independent of this proposal, and should be its own RFC following the normal process.
In other replies on this thread you've emphasised the role of feature maintainers, but the RFC doesn't go into much detail about how that role will work. Will it be like maintaining a PIE extension, committing code directly, but in a directory of php-src? Or are other members of the community expected to review their code and merge it?
I think this RFC is trying to do two conflicting things at once:
1) allow users to test far-reaching, experimental, changes to the language and engine
2) allow users to enable safe, stable, features without installing untrusted binaries
For problem 1, what we need is a way to get usable builds into the hands of users from experimental branches of the source. If CI tooling and release packaging can be automated enough, there's no reason to limit it to just one "community" branch.
For problem 2, we need stronger guarantees of stability, not weaker ones: better sandboxing so people trust extensions more, perhaps; or more feature flags within the existing release cycle.
There's some interesting ideas in here, but I don't think they're workable as presented.
Rowan Tommins
[IMSoP]
---
## #130325 — Christian Schneider — 2026-03-15T11:11:57+00:00
URL: https://externals.io/message/130313#130325 · In reply to: #130323
Am 15.03.2026 um 11:33 schrieb Rowan Tommins [IMSoP] :
> > […]
>
> 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?
>
> 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).
> > […]
>
> 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
---
## #130328 — Daniil Gentili — 2026-03-15T11:54:25+00:00
URL: https://externals.io/message/130313#130328 · In reply to: #130313
Bumped the RFC with some clarifications based on the arguments presented here and elsewhere.
### Changelog
#### 1.0.1
- **New section: [Sandboxing](#sandboxing)** — Moved sandboxing content into its own dedicated section.
Clarified that sandboxing does not cover external extensions that may be installed i.e. through PIE, but they may choose to opt-in and respect sandboxing levels as well, if they wish.
Clarified that sandboxing is absolutely mandatory for the implementation of the main goal of php-community: fast adoption of new features by the entire PHP community, especially shared hosts, which require sandboxing by definition, and cannot be expected to look through the list of changes in all feature extensions bundled in all of the monthly releases of php-community.
In fact, one of the reasons why shared hosts often lag behind PHP versions is the (small, but non-negligible) cost of searching and patching sandbox escape hatches introduced by new PHP versions, so sandboxing, if merged in mainline PHP, may also speed up adoption of even normal PHP upgrades.
- **New section: [Requirements to succeed](#requirements-to-succeed)**
In order for `php-community` to succeed at its goal of making experimental features more accessible, major frameworks and libraries need to start relying on features initially only present in `php-community`.
For this purpose, most new PHP features should get proposed to `php-community` first, instead of normal PHP, in order to speed up adoption of both those features and of `php-community` itself.
In fact, the normal RFC process could also be altered to **require** all new features to pass through community RFCs, first.
To further increase adoption, the PHP Feature Extensions API may also be offered on normal PHP versions, either for especially mature feature extensions to get even more adoption data, or for all feature extensions, perhaps even skipping the separate `php-community` distro altogether (though some of its properties like a stable release schedule not movable by security updates are still preferred).
- **Voting (clarification)** — Better spelled out that internals has veto rights: if 50%+1 of internals members vote Abstain or abstain from voting altogether, the community RFC is vetoed.
- **Community RFC owners (clarifications)**
Crucially, the maintenance burden of feature extensions will lay **exclusively** on the feature owners, not `php-src` maintainers.
Features and bug fixes for feature extensions will **NOT** be a responsibility
of `php-src` maintainers.
This also includes reviews on feature extension code, which will be a responsibility mainly of the owners of said features.
Of course, a more detailed review on behalf of php-src maintainers is still preferable for the initial addition PR, but it is not required (even if obviously still allowed) for subsequent PRs.
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).
Developers outside of the feature owners should only need to touch feature extension code when introducing breaking changes to extension APIs, like is already the case now for core extensions.
This is actually very close to the approach used by linux: drivers are owned and maintained each by their own maintainers: non-maintainers need to touch driver code only when authoring breaking changes to inner Linux APIs which affect drivers.
- **Removal of community RFC features (clarification)** — Added note comparing the situation to long-standing legacy extension code in `php-src`; real adoption statistics from Packagist will make removal decisions significantly easier in `php-community`, compared to mainline PHP.
- **Release process (clarifications)** — Package maintainers should pin to specific feature extension versions (e.g. `feature-performance:^2`), not to specific `php-community` releases. The `PhpFeature` API and scaffolding code is itself exposed as a versioned, always-enabled `php-community` feature extension.
- **Feature extensions (clarification)** — Expanded rationale for supporting multiple concurrent versions of the same feature extension, particularly for deprecation/removal features that would otherwise introduce undue pain in an experimental channel.
- **API (clarification)** — The `PhpFeature` API (and eventually even feature extensions) could be made available in normal PHP for forward compatibility.
>
>
>
> Hello internals,
>
> 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.
>
> As anticipated by Edmond Dantes in an earlier thread, I'm now part of the True Async committee.
>
> I decided to not present the RFC as explicitly linked to True Async, to explicitly prevent an interpretation where it is something that will allow us to "sneak in" True Async into PHP.
>
> True Async is one of, but not the only nor the main reason why I created this RFC.
>
> I truly believe that PHP could really benefit from a more agile community RFC process, that can transform it from just a decent and fast language I and so many others love, to an amazing, blazing fast and actually modern and ergonomic language.
>
> I believe PHP truly deserves this.
>
> Kind regards,
> Daniil Gentili.
>
> —
>
> Daniil Gentili - Senior software artisan
> Website: https://daniil.it
> GitHub: https://github.com/danog
> Email: daniil@daniil.it
---
## #130329 — Edmond Dantes — 2026-03-15T12:08:11+00:00
URL: https://externals.io/message/130313#130329 · In reply to: #130325
Hello
> I was thinking along the same lines but it also made me wonder: Who would target such an unstable community version for production?
There are several possibilities:
1. Use the experimental version to try writing something new on it and
thus explore how good the implementation actually is.
2. Some projects may even be willing to take the risk in production,
provided the code is stable enough. In other words, I don’t rule out
that this could be interesting to someone.
----
Ed
---
## #130330 — Daniil Gentili — 2026-03-15T12:20:22+00:00
URL: https://externals.io/message/130313#130330 · In reply to: #130323
>
>
> > […]
>
> Who is going to create and maintain these packages? Who decides which distros, which versions, etc? Like sandboxing, this could fill an RFC on its own.
>
Initially me as the author of the RFC, then php-src maintainers.
Splitting up this RFC into sub-RFCs is not an issue to me, but I would prefer to get a general positive consensus before spending more time on actual implementation.
>
> > […]
>
> How will this work, code-wise? Are these versions actually separate implementations side by side, or limited to changes that can be represented with feature flags?
>
> What is the minimum lifetime and lifecycle of these versions? Can a version be retired early if it has an unsolvable stability or security issue?
>
Clarified that this was mainly meant for removal/deprecation feature extensions.
The exact lifecycle is explicitly not defined to allow for more flexibility, but it can have emergency yanks for security issues, just like for all extensions.
>
> > […]
>
> I don't think we have any suitable definition of "internals members" that can apply here. Do you mean people with commit access to the php-src repo? Or are you hoping to cross-check GitHub users against main.php.net accounts (as used by the current voting widget) somehow?
>
By internals members I mean users with current voting rights, who will provide their GitHub nicknames.
>
> > […]
>
> 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?
>
> 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.
>
The point here is that users MUST be able to rely on feature extensions, including in the long-term: this is the reason for the stringent removal requirements.
>
> > […]
>
> 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?
>
>
The feature owners handle all changes to feature extensions.
Normal PHP RMs handle merging stable PHP into the community branch.
> > […]
>
> Is there something that makes this automation easier for community releases than regular ones? Or is automaton of the existing process something that needs to be done before we can consider this RFC?
>
It can be applied to regular ones as well, but it was added mainly to work around the fact that normal PHP already has third-party distro packaging, while php-community will not, unless it is provided from the start by php.net directly.
>
> > […]
>
> If there are failing tests in a particular feature when it's time to tag a community release, what happens? Does the release get delayed until the maintainer of that feature fixes it?
>
Feature maintainers cannot merge a failing PR, just like with all other php-src PRs.
>
> > […]
>
> Who will be responsible for the stability of this branch? This is really important, because you're targeting this concept at shared hosts, who want to know the software they're running is stable and secure.
>
The feature authors, backed by the judgement of internals members and php-src maintainers.
> Why will somebody trust this branch containing a bunch of separately-maintained feature extensions any more than they would trust a repository of PIE extensions? If anything, it is far *more* dangerous, because the features aren't limited to the normal extension API.
Sandboxing plays the single most important rule in building trust.
> > […]
>
> By definition, the sandbox mechanism needs to exist outside of the feature extension system, and be stable across community versions. As others have said, it's basically independent of this proposal, and should be its own RFC following the normal process.
>
Yes, absolutely.
>
> In other replies on this thread you've emphasised the role of feature maintainers, but the RFC doesn't go into much detail about how that role will work. Will it be like maintaining a PIE extension, committing code directly, but in a directory of php-src? Or are other members of the community expected to review their code and merge it?
>
Clarified now, mainly it’s like maintaining a PIE extension committing code directly to php-src, with *some* supervision from php-src maintainers (mainly just a basic qualitychecks), crucially little impact on the actual API and design (which is the main way to reduce load on php-src maintainers).
>
> I think this RFC is trying to do two conflicting things at once:
>
> 1) allow users to test far-reaching, experimental, changes to the language and engine
> 2) allow users to enable safe, stable, features without installing untrusted binaries
>
These are not conflicting things, they complement each other.
> For problem 1, what we need is a way to get usable builds into the hands of users from experimental branches of the source. If CI tooling and release packaging can be automated enough, there's no reason to limit it to just one "community" branch.
>
Actually, the second php-community distro could theoretically be skipped altogether, shipping PhpFeatures into normal PHP, which would likely increase adoption even more.
> For problem 2, we need stronger guarantees of stability, not weaker ones: better sandboxing so people trust extensions more, perhaps; or more feature flags within the existing release cycle.
Sandboxing is expected to cover this.
>
>
Regards,
Daniil Gentili.
---
## #130331 — Daniil Gentili — 2026-03-15T12:22:56+00:00
URL: https://externals.io/message/130313#130331 · In reply to: #130325
> > […]
>
> 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.
>
> > […]
>
> 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.
---
## #130332 — Daniil Gentili — 2026-03-15T12:42:21+00:00
URL: https://externals.io/message/130313#130332 · In reply to: #130313
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.
---
## #130333 — s.hulard@chstudio.fr — 2026-03-15T13:01:45+00:00
URL: https://externals.io/message/130313#130333 · In reply to: #130332
Hello !
Le dimanche 15 mars 2026 à 13:44, Daniil Gentili 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
https://chstudio.fr
---
## #130334 — Daniil Gentili — 2026-03-15T13:45:07+00:00
URL: https://externals.io/message/130313#130334 · In reply to: #130333
>
> 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.
---
## #130335 — Ben Ramsey — 2026-03-15T13:47:51+00:00
URL: https://externals.io/message/130313#130335 · In reply to: #130329
> Hello
>
> > […]
>
> There are several possibilities:
> 1. Use the experimental version to try writing something new on it and
> thus explore how good the implementation actually is.
> 2. Some projects may even be willing to take the risk in production,
> provided the code is stable enough. In other words, I don’t rule out
> that this could be interesting to someone.
>
> ----
> Ed
Shared hosting companies aren't going to take that risk.
Any company that runs an online business isn't going to take that risk.
If companies were willing to take this kind of risk, we'd see them
running production workloads on RCs leading up to the next major version
of PHP, but that's not happening.
PHP needs a much different ethos and ecosystem for something like this
to work.
Cheers,
Ben
---
## #130336 — Ben Ramsey — 2026-03-15T13:55:51+00:00
URL: https://externals.io/message/130313#130336 · In reply to: #130332
> 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
---
## #130337 — Daniil Gentili — 2026-03-15T13:56:44+00:00
URL: https://externals.io/message/130313#130337 · In reply to: #130335
>
>
> Shared hosting companies aren't going to take that risk.
>
Arguments like these make me increasingly convinced that PhpFeatures should
just ship in normal PHP, without a separate distro.
Sandboxing offers all the needed security requirements, ensuring shared
host adoption while allowing frameworks to rely on feature extensions
shipped in normal PHP.
>
> Any company that runs an online business isn't going to take that risk.
>
Companies may or may not use those features, it is up to them.
What is important is that environments *allow* the usage of feature
extensions.
>
>
> PHP needs a much different ethos and ecosystem for something like this
> to work.
>
Talking about what the PHP ecosystem needs as a requirement for improvement
X will lead us nowhere, and is precisely the reason for this RFC.
---
## #130338 — Daniil Gentili — 2026-03-15T14:01:06+00:00
URL: https://externals.io/message/130313#130338 · In reply to: #130336
>
>
> 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.
---
## #130339 — Ben Ramsey — 2026-03-15T14:10:48+00:00
URL: https://externals.io/message/130313#130339 · In reply to: #130322
> Hello!
>
> > […]
>
> It seems to me this is an organizational problem that certainly has a
> good solution.
> In my company we also use something similar.
> In practice it does not require that much effort. Moreover, right now
> I am doing essentially the same thing for the TrueAsync project:
>
> - the php-src code is updated
> - tests are run
> - if the tests pass, the code proceeds further
>
> I am doing this manually, although the process could be automated.
> TrueAsync currently has about 18,000+ lines of changes in PHP-SRC.
> Over these six months my personal attention was required only 2–3
> times. I can confirm a similar experience with other projects as well.
> A large number of different solutions can be devised here, both at the
> level of flow and rules, and at the level of technical approaches. So
> yes, it is a problem.
> But it is a problem that has a solution.
>
I worked on an automated release workflow[^1] for php-src a few years
ago, but after discussions with others from various major project
communities (including Apache, Linux, etc.), I realized the solution
wasn't workable for one main reason:
An automated workflow cannot sign builds and still be considered secure.
Builds must be signed by a human on the machine where the build took
place. Automating the signatures in the cloud significantly reduces
trust and greatly increases the likelihood of a bad actor gaining access
to sneak things into the build (e.g., through compromised GitHub
Actions, etc.).
This was the nearly universal advice I was given by folks from other
communities in 2023. I doubt that it's changed much since then, and
especially with the rise of software supply chain attacks, it's probably
even more relevant today.
Cheers,
Ben
[^1]: https://github.com/php/php-src/pull/10604
---
## #130340 — Ben Ramsey — 2026-03-15T14:14:24+00:00
URL: https://externals.io/message/130313#130340 · In reply to: #130338
> > […]
>
> 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
---
## #130341 — Rob Landers — 2026-03-15T14:18:06+00:00
URL: https://externals.io/message/130313#130341 · In reply to: #130340
>
> > […]
>
> 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
---
## #130342 — Jakub Zelenka — 2026-03-15T14:31:49+00:00
URL: https://externals.io/message/130313#130342 · In reply to: #130313
Hi
On Sat, Mar 14, 2026 at 7:34 PM Daniil Gentili
wrote:
>
> Hello internals,
>
> Submitting for discussion the php-community RFC, for a faster-moving,
> community-driven PHP: https://wiki.php.net/rfc/php-community
>
>
I don't understand the security part. Do you mean that people could report
security issues for those community branches? If so, then it's completely
unrealistic as we are already struggling with handling security issues for
the current branches. And if not, then I don't think anyone would be
running it production so I'm not really sure this would be really useful
(meaning there is no point to have it in php-src - you could just create
your own fork and provide releases from it as it would be just play tool).
Cheers
Jakub
---
## #130343 — Daniil Gentili — 2026-03-15T14:51:04+00:00
URL: https://externals.io/message/130313#130343 · In reply to: #130342
I don't understand the security part. Do you mean that people could report
> security issues for those community branches? If so, then it's completely
> unrealistic as we are already struggling with handling security issues for
> the current branches.
>
I honestly do not consider seriously any argument based on "it's too much
load for maintainers", including around security (which is still a
responsibility of feature owners).
PHP is one of the most used programming languages in the world.
The PHP foundation, and by proxy its sponsors, are actively paying php-src
maintainers in order to not just make PHP secure, but also improve it in
every way possible (unlike myself and Edmond, as we are both working as
unpaid volunteers, investing a huge amount of time to develop and push
major improvements to the language, for free).
I honestly do not believe that sponsors actually paying the php-src
maintainers would be against the introduction of genuinely useful, quality
of life improvements like async, generics, etc just on the basis that it
would be too much work for php-src maintainers.
Yes, it would be more work.
Yes, PHP needs this to become a better language and compete with other
modern languages.
---
## #130344 — Daniil Gentili — 2026-03-15T14:55:30+00:00
URL: https://externals.io/message/130313#130344 · In reply to: #130339
>
>
> I worked on an automated release workflow[^1] for php-src a few years
> ago, but after discussions with others from various major project
> communities (including Apache, Linux, etc.), I realized the solution
> wasn't workable for one main reason:
>
> An automated workflow cannot sign builds and still be considered secure.
>
> Builds must be signed by a human on the machine where the build took
> place. Automating the signatures in the cloud significantly reduces
> trust and greatly increases the likelihood of a bad actor gaining access
> to sneak things into the build (e.g., through compromised GitHub
> Actions, etc.).
>
I strongly disagree.
I have way more trust in an automatic build environment with reproducible
(key word here) builds than in a (potentially corruptible) human that
pinkie swears no changes were made to an autogenerated configure contained
in released tarballs.
---
Next page: https://externals.io/message/130313.md?page=2