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

Mailing Lists php.internals
1

On 14 March 2026 18:32:24 GMT, Daniil Gentili <daniil.gentili@gmail.com> wrote:

Submitting for discussion the php-community RFC, for a faster-moving, community-driven PHP: PHP: 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 :+1: = Accept, :-1: = Reject, :eyes: = 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]

2

Am 15.03.2026 um 11:33 schrieb Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk>:

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.

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).

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?

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

3

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

4

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.

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.

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?

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.

internals members through GitHub :+1: = Accept, :-1: = Reject, :eyes: = 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?

By internals members I mean users with current voting rights, who will provide their GitHub nicknames.

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.

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.

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?

The feature owners handle all changes to feature extensions.

Normal PHP RMs handle merging stable PHP into the community branch.

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?

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.

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?

Feature maintainers cannot merge a failing PR, just like with all other php-src PRs.

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.

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.

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.

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.

5

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.

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.

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?

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.

6

On 3/15/26 07:08, Edmond Dantes wrote:

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

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

7

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.

8

Hello

Any company that runs an online business isn't going to take that risk.

At one time we considered Swoole as the only solution for our task,
even though it was a risk.
If we had been a startup, I think we would have made a positive decision.
I hope no one is seriously considering using experimental features in
places where stability is required.
We should assume that everyone participating in this discussion is
acting in good faith and with sound judgment.

---
Ed

9

On 15/03/2026 12:20, Daniil Gentili wrote:

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.

[...]

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.

[...]

The feature owners handle all changes to feature extensions.

You can't have it both ways:

- either the PHP project is making a lasting promise to the user by accepting a feature extension, and therefore taking on a lasting obligation;

- or, the obligation is entirely on the feature owner, and therefore the PHP project can't make any promise to the user

Currently, we have a process for promising a feature will be supported "forever" (RFCs); and a mechanism for maintainers to make an independent promise which users can choose whether to trust (PIE).

It might be interesting to make a more limited promise, such as "this feature will be supported for 1 year, then subject to breaking changes or removal". It might even be sensible to automatically "time out" every feature version after, say, 1 year, forcing one of three things: a) the feature has proven useful and stable, and is adopted permanently; b) the feature is still in flux, and users should migrate to a newer version; c) the feature has been abandoned, or proven impractical, and will no longer be provided.

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.

This is a very different type of "sandboxing" than what is discussed in the RFC. We're not talking about "ask the extension nicely not to give the user file system access", we're talking about "trust the extension not to silently send all user input to a malicious server", and "trust the extension not to have memory leaks that will crash the entire host".

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.

Perhaps the confusion is that there are two different kinds of stability we can talk about:

- stability of the implementation: are the changes to the engine thoroughly tested, and free from crashes and incorrect behaviour?

- stability of the API: can PHP code, and other extensions, be written to make use of the feature?

A feature flag is suitable for hiding an unstable API, but it's not suitable for hiding an unstable implementation.

--
Rowan Tommins
[IMSoP]