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

1 month ago by Christian Schneider — view source — reply

unread

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

1 month ago by Daniil Gentili — view source — reply

unread

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.

1 month ago by Ilija Tovilo — view source — reply

unread

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

1 month ago by Daniil Gentili — view source — reply

unread

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.

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:

Adoption is negligible, as evidenced by Packagist statistics.

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.

1 month ago by Ilija Tovilo — view source — reply

unread

Hi Daniil

Thanks for your response.

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.

In practice, many people propose one RFC and then move on to some
other project. I think it's an unrealistic expectation that they will
stick around for maintenance.

In the likely case that the original proposer stops maintaining the
feature, it cannot be removed if it has been adopted by users,
according to this RFC. So the code will sit around and rot, and the
feature might break completely. Will end-users understand this
distinction or blame the PHP Foundation for not fixing their issues?
Will they blame us for degrading quality?

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.

But this code doesn't live in isolation. If it would, the feature
could just be added to an extension and the problem would be solved.
But many features require changes to the engine, which is prone to
bugs, performance regressions and security issues that impact the
whole system. If this code is changed by guests and not reviewed by
maintainers, how do we prevent the community edition from constantly
breaking, or backdoors from being added by unknown people? Who will
merge changes and bug fixes from the stable branches and master? Who
will fix interactions between community-only features? Or as Jakub
mentioned, who will handle security issues? These are several
full-time jobs.

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.

FWIU, if the community votes are all upvotes (which is not rare for
GitHub, the community is more enthusiastic and optimistic than
internals), a single upvote from an internals person will reach the
50+% threshold. It's also worth noting that GitHub Upvotes can be
bought.

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

Linus also has a special authority over Linux. He has removed
components in the past over disagreements. Nobody in the PHP community
has this kind of authority.

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.

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

Yes, this is absolutely true. And that's also why the RFC threshold
was increased to 2/3s, and why new additions are heavily scrutinized.
I understand that this can be incredibly frustrating (I was in that
boat myself many times) but it's also true that undoing mistakes is
much harder than not making the mistake in the first place.

Ilija

1 month ago by Daniil Gentili — view source — reply

unread

Version 1.1.0 of the RFC was published:

1.1.0

Voting (clarification) — Clarified that only internals members with voting rights count for quorum/veto calculations, and emphasized internals-only quorum wording.
Community RFC owners (clarification) — Clarified that compatibility fixes caused by breaking internal PHP API changes are handled by whoever introduces those breaking changes.
Removal of community RFC features (policy update)

Removal voting remains open to all for sentiment, but only internals votes are counted for outcome.

Eligibility changed from strict AND conditions to an OR policy:

no active owners (defined as no commits and no replies from listed owners in 6 months; with owner removal possible in case of violations);
or negligible adoption, based on Packagist stats/telemetry.

Deprecation period after acceptance of a removal RFC was reduced from at least 3 stable php-community releases to at least 1 stable release.

Feature extensions (new clarifications) — Added guidance that releases should ideally ship all major versions of feature extensions together, that security updates apply to all currently shipped versions, and that retiring old majors is up to feature owners based on adoption.

1 month ago by Daniil Gentili — view source — reply

unread

Hi Ilija,

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.

In practice, many people propose one RFC and then move on to some
other project. I think it's an unrealistic expectation that they will
stick around for maintenance.

In the likely case that the original proposer stops maintaining the
feature, it cannot be removed if it has been adopted by users,
according to this RFC. So the code will sit around and rot, and the
feature might break completely. Will end-users understand this
distinction or blame the PHP Foundation for not fixing their issues?
Will they blame us for degrading quality?

Thanks for your feedback, indeed removal could be handled better.

Updated the removal policy in 1.1.0 based on your feedback: https://wiki.php.net/rfc/php-community#section110

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.

But this code doesn't live in isolation. If it would, the feature
could just be added to an extension and the problem would be solved.
But many features require changes to the engine, which is prone to
bugs, performance regressions and security issues that impact the
whole system. If this code is changed by guests and not reviewed by
maintainers, how do we prevent the community edition from constantly
breaking, or backdoors from being added by unknown people? Who will
merge changes and bug fixes from the stable branches and master? Who
will fix interactions between community-only features? Or as Jakub
mentioned, who will handle security issues? These are several
full-time jobs.

I am fully aware that this is a lot of work.

It is the work of language maintainers, it’s what they do, and I understand that adding more to your already full plates can be a problem.

However, as I mentioned earlier, appropriate workload reprioritisation in favour of php-community would be an investment into future PHP and PHPF funding growth.

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.

FWIU, if the community votes are all upvotes (which is not rare for
GitHub, the community is more enthusiastic and optimistic than
internals), a single upvote from an internals person will reach the
50+% threshold. It's also worth noting that GitHub Upvotes can be
bought.

No, only internals votes count towards the veto, clarified this.

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

Linus also has a special authority over Linux. He has removed
components in the past over disagreements. Nobody in the PHP community
has this kind of authority.

Well, just for php-community, I suppose a benevolent dictator might be chosen.

I believe you could fit the role, if you would be unavailable for this I could step in :)

Anyway, as a disclaimer, I fully intend to push php-community and true async ONLY with the agreement of internals and the phpf.

Even in our different views, we all care about PHP in different ways: I respect this, and I have absolutely no intention to just make a new fork of PHP (and I have advised Edmond against doing this as well for True Async).

I want the best for PHP.

For this to work, I will only proceed with the consensus of internals, who are all historical figures in PHP, each one has contributed a lot to this language.

Kind regards,
Daniil Gentili.

1 month ago by Edmond Dantes — view source — reply

unread

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

1 month ago by Ben Ramsey — view source — reply

unread

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.

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 month ago by Daniil Gentili — view source — reply

unread

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.

1 month ago by Ben Ramsey — view source — reply

unread

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.

That's why the builds are signed, and the keys used to sign the builds
are also signed by other, trusted parties. If the human who builds it
introduces any changes, we can trace it directly to them because they
signed that build. If their key was compromised, they revoke the key,
and the build's signature now shows as valid but using a revoked key, so
others know not to trust it.

Cheers,
Ben

1 month ago by Edmond Dantes — view source — reply

unread

An automated workflow cannot sign builds and still be considered secure
Thank you for pointing out this aspect. However, my message was about
something slightly different.

1 month ago by Rowan Tommins [IMSoP] — view source — reply

unread

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:

allow users to test far-reaching, experimental, changes to the language and engine
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]

1 month ago by Christian Schneider — view source — reply

unread

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

1 month ago by Edmond Dantes — view source — reply

unread

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:

Use the experimental version to try writing something new on it and
thus explore how good the implementation actually is.
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

1 month ago by Ben Ramsey — view source — reply

unread

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:

Use the experimental version to try writing something new on it and
thus explore how good the implementation actually is.

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

1 month ago by Daniil Gentili — view source — reply

unread

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.

1 month ago by Edmond Dantes — view source — reply

unread

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

1 month ago by Daniil Gentili — view source — reply

unread

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.

1 month ago by Daniil Gentili — view source — reply

unread

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 👍 = 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?

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 http://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:

allow users to test far-reaching, experimental, changes to the language and engine

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.

1 month ago by Rowan Tommins [IMSoP] — view source — reply

unread

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:

allow users to test far-reaching, experimental, changes to the
language and engine

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]

1 month ago by Daniil Gentili — view source — reply

unread

Bumped the RFC with some clarifications based on the arguments presented here and elsewhere.

Changelog

1.0.1

New section: 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

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 https://daniil.it/
GitHub: https://github.com/danog
Email: daniil@daniil.it

1 month ago by Daniil Gentili — view source — reply

unread

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.

1 month ago by s.hulard@chstudio.fr — view source — reply

unread

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
https://chstudio.fr

1 month ago by Daniil Gentili — view source — reply

unread

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.

1 month ago by Ben Ramsey — view source — reply

unread

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

1 month ago by Daniil Gentili — view source — reply

unread

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.

1 month ago by Ben Ramsey — view source — reply

unread

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

1 month ago by Rob Landers — view source — reply

unread

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

1 month ago by Daniil Gentili — view source — reply

unread

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.

1 month ago by Rob Landers — view source — reply

unread

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

1 month ago by Daniil Gentili — view source — reply

unread

Il dom 15 mar 2026, 16:21 Rob Landers rob@bottled.codes ha scritto:

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

1 month ago by Ben Ramsey — view source — reply

unread

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

1 month ago by Jakub Zelenka — view source — reply

unread

Hi

On Sat, Mar 14, 2026 at 7:34 PM Daniil Gentili daniil.gentili@gmail.com
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

1 month ago by Daniil Gentili — view source — reply

unread

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.

1 month ago by Jakub Zelenka — view source — reply

unread

On Sun, Mar 15, 2026 at 3:51 PM Daniil Gentili daniil.gentili@gmail.com
wrote:

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

Except feature owners won't be able do any triaging, security impact
analysis (deciding whether it's a security issue - this is done by the
security team), allocating CVE's, test the patches in our security repo, do
the security release and publishing / updating all advisories. And I'm not
even considering extra reporting will be required by CRA. So I think you
might be underestimating the amount of work for handling security issues.

Kind regards,

Jakub

1 month ago by Daniil Gentili — view source — reply

unread

Il dom 15 mar 2026, 16:36 Jakub Zelenka bukka@php.net ha scritto:

On Sun, Mar 15, 2026 at 3:51 PM Daniil Gentili daniil.gentili@gmail.com
wrote:

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

Except feature owners won't be able do any triaging, security impact
analysis (deciding whether it's a security issue - this is done by the
security team), allocating CVE's, test the patches in our security repo, do
the security release and publishing / updating all advisories. And I'm not
even considering extra reporting will be required by CRA. So I think you
might be underestimating the amount of work for handling security issues.

I do not underestimate it, I simply do not consider it to be a problem,
given the context of PHP needing a LOT of new features in order to compete
with modern languages.

Userland has been pollyfilling them left and right (static analysis,
amphp), but this is not the way forward.

A serious discussion needs to be done around a simple question.

Does internals want to keep PHP mostly as-is, in de facto maintainance mode
(just security fixes, no expensive major features) to reduce the workload
on maintainers, and slowly creep into irrelevance?

Because this is, put bluntly, what is being proposed.

1 month ago by Jakub Zelenka — view source — reply

unread

On Sun, Mar 15, 2026 at 4:46 PM Daniil Gentili daniil.gentili@gmail.com
wrote:

Il dom 15 mar 2026, 16:36 Jakub Zelenka bukka@php.net ha scritto:

On Sun, Mar 15, 2026 at 3:51 PM Daniil Gentili daniil.gentili@gmail.com
wrote:

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

Except feature owners won't be able do any triaging, security impact
analysis (deciding whether it's a security issue - this is done by the
security team), allocating CVE's, test the patches in our security repo, do
the security release and publishing / updating all advisories. And I'm not
even considering extra reporting will be required by CRA. So I think you
might be underestimating the amount of work for handling security issues.

I do not underestimate it, I simply do not consider it to be a problem,
given the context of PHP needing a LOT of new features in order to compete
with modern languages.

But we just don't have those resources in security team. As I said we are
struggling to handle the current load. Things might improve in 2027 but
that's still not clear if we get some extra resources. If we do, we would
more likely want to spend it on the current backlog and improve other
things though as there is a lot to do. So I just don't think something like
this is realistic.

Kind regards,

Jakub

1 month ago by Larry Garfield — view source — reply

unread

Except feature owners won't be able do any triaging, security impact analysis (deciding whether it's a security issue - this is done by the security team), allocating CVE's, test the patches in our security repo, do the security release and publishing / updating all advisories. And I'm not even considering extra reporting will be required by CRA. So I think you might be underestimating the amount of work for handling security issues.

I do not underestimate it, I simply do not consider it to be a problem,
given the context of PHP needing a LOT of new features in order to
compete with modern languages.

Userland has been pollyfilling them left and right (static analysis,
amphp), but this is not the way forward.

A serious discussion needs to be done around a simple question.

Does internals want to keep PHP mostly as-is, in de facto maintainance
mode (just security fixes, no expensive major features) to reduce the
workload on maintainers, and slowly creep into irrelevance?

Because this is, put bluntly, what is being proposed.

Calling the status quo "de facto [maintenance] mode" is either a statement of total ignorance, trolling, or just being offensive. I will allow others to decide which they feel it is. We routinely have static analysis maintainers objecting to how FAST the language moves, not how slow. PHP is one of the most rapidly evolving languages on the market (at least of those that have actual market share and use and aren't still pre-release experiments).

Those new features may not be the ones you personally would prioritize, but it is patently absurd to call PHP in "maintenance mode." Even a cursory glance at the changelog for 8.5 and 8.4 will show many significant new feature additions from many people, often inspired by other languages to "close the gap" with those languages. Just because someone disagrees with your "php-unstable" proposal doesn't mean they're against the language improving. Come on, you're better than that.

As to the proposal itself, aside from the many logistical and governance issues that others have pointed out already, there's a more fundamental problem that Ben raised and seems to have been dismissed: It simply won't work.

Let's look at a concrete example: The Asymmetric Visibility RFC.

First problem: This feature involved adding new syntax to the language that wasn't just sugar for some other syntax. That means changes to the syntax definition, to the compiler, and to the runtime engine. None of those are especially "pluggable" right now. So an easily enabled/disabled extension would simply not be able to do it. It would have to be effectively a fork, at minimum of the .y file that drives the parser. And syntax changes are the types of PR that tend to have merge conflicts most often, because there's a lot of "index of stuff" files that need to be updated, and two parallel RFCs almost certainly will collide. That means a fork with lots of conditionals in it to disable the syntax. We're talking feature flags, not extensions.

Now, feature-flags aren't a bad thing; They can be quite useful. But they do add complexity, and it means maintaining php-community as a separate branch/repo/whatever from php-src:master is going to be an ongoing problem, just at a basic git merge level.

If we were talking about a different feature that could be fully contained to an extension... then we already have a way to pre-release those: It's called extensions. If we had wanted to, for example, ship ext/Random as a stand-alone random extension via pecl/pie for a while first to get feedback on the API, that's already possible today. Just release an extension and tag it alpha, and then later on we can copy it into php-src when we decide it's ready. No changes needed.

Second problem: What data would have benefited the aviz RFC? There's two possibilities:

Would you actually use this?
Is this the syntax/semantics that work for you?

Both of these fail for the same reason: The feature is not yet locked down, by definition.

There was a lively (and entirely valid and useful) discussion on aviz about what syntax to use. Let's suppose that we released a php-community version of aviz that used the public:private style syntax, to see what happens. Then we'd want to see if we should shift that to public private(set) (as we ended up using).

As Ben pointed out, nobody is going to use it in production. It would be foolish for them to do so, because we're explicitly saying "we could change the syntax for this next month, fair warning." I certainly wouldn't use it for anything more than noodling around on my laptop a bit. I wouldn't even use it in my casual OSS work if I knew it was subject to change. Organizations that rely on PHP as enterprise-critical already have to be cajoled and prodded and begged to update to new stable versions of PHP. There won't be any meaningful usage of php-syntax-unstable outside of devs futzing around on their own laptops. So however the telemetry is collected (via Packagist or otherwise), the data will be largely useless for telling us how likely it is that a feature would have widespread adoption once stable (for some definition of widespread).

That also means that feedback on the syntax/semantics couldn't really be trusted, because it's not getting the "real world" use that is desired. And that sort of feedback ("The colon is clumsy, I'd prefer the parens" or vice versa) is not something telemetry would even be able to provide. It would require real people coming to Internals (either the list or GIthub or whatever) and writing words to tell us that. Which... is already the case.

Now, let's look at the opposite problem. Suppose people do start using the pre-release aviz for serious work, and it's running in prod somewhere. Then we determine "actually, we really do want to support more operations than just get/set, so we have to use the parens syntax so we can put words other than 'set' in there." Except... crap, if we do that, we'll break all of those production sites that are running with the colon version. So now we can't change it, even though it's an unstable feature. If we did, it would break a bunch of people's production sites. That would be... extremely bad for PHP's image and adoption in business.

Of course, we have the same problem today with stable releases: Once something ships, we can't change it anymore without breaking prod. So we're stuck with it. So either a community-prerelease feature is not used, and we get no meaningful data, or it does get used and then we're stuck with the current form of it, which is no different from today with stable releases. At best, we gain nothing.

We've seen that pre-release syntax can backfire, badly. The best example is CSS: There was a time when browsers would put out pre-release versions of syntax, with a prefix: -webkit-border-radius and such. But then... anyone who used that property in prod needed it to be there forever. You only get to define how -webkit-border-radius works once. You could define -ie-border-radius differently, perhaps, but that was bad for everyone as now they needed to deal with two different syntaxes that may work differently, or worse, don't work differently but you still have to repeat them. That whole approach was eventually declared a failure and abandoned.

We ran into this when developing PSR-14, too. At one point, we had three separate package repositories when there was a harder separation between bidirectional and unidirectional events. Eventually we redesigned it to have no such distinction and cut back down to a single repo, which is what became the official spec. Some time later I deleted the other repos as unnecessary... and someone showed up in our GitHub issues furious that we had broken their site because they were using those temporary 0.4-tagged repositories in their application! No one wins in that situation.

What CSS does now instead is, er, really intensive collaboration and planning (like we do), and then releasing pre-release features behind client-side feature flags. Meaning using a pre-release feature in production is, well, kinda pointless, because 99.9% of viewers of your site will not have that secret flag enabled, so wouldn't see it anyway. It's only useful for the developer to noodle around on their own machine and get enough of a feel for it to give meaningful feedback. And that is valuable.

So the actually useful goal here, if we want better quality feedback, isn't to have a quasi-supported "PHP with features that we may or may not break later." It's to make it easier for devs to noodle with the proposal locally to get their hands dirty. 3v4l has a feature that lets you run code snippets against certain PR branches, but that is very manual and selective so only of limited use.

A much, much more useful approach would be to devise some way to automatically build docker images out of PRs against php-src. So if you download the php-dev-aviz-2024-03-10 docker image, it's easy to run it and see what the code "feels like," but no one is going to mistake it for a stable, production-usable image they can build a business on. (Well, almost no one; I'm sure someone will try, but it's a lot easier then to say "it's your own damned fault for running some rando PR in production".)

That would allow devs to more easily "try out" a feature and report back manually. That potentially improves the quality of feedback from "I read the syntax in the RFC and I don't like X" to "I tried writing a class with this syntax and I kept mistyping it because it's fugly". Or perhaps not, but at least it is vastly lower effort to do. The Async people are already doing this, which is very good! All we need is make that easier and more automated to do for any RFC.

I want the async work to succeed. I have ample issues with the current proposal, but it is still the best proposal we've had to date for async and I want it to continue to evolve into something we can ship. But that doesn't mean creating a mess of land mines and useless telemetry and a lot of extra work for maintainers, paid or volunteer.

I have been a very outspoken critic of the current RFC process for many reasons. I do appreciate the interest in adapting it to make it better. But any such proposal should actually make it, well, better. Not more cumbersome and involved for maintainers for no meaningful return on investment.

--Larry Garfield

1 month ago by Ben Ramsey — view source — reply

unread

A much, much more useful approach would be to devise some way to
automatically build docker images out of PRs against php-src. So if
you download the php-dev-aviz-2024-03-10 docker image, it's easy to
run it and see what the code "feels like," but no one is going to
mistake it for a stable, production-usable image they can build a
business on. (Well, almost no one; I'm sure someone will try, but
it's a lot easier then to say "it's your own damned fault for
running some rando PR in production".)

That would allow devs to more easily "try out" a feature and report
back manually. That potentially improves the quality of feedback
from "I read the syntax in the RFC and I don't like X" to "I tried
writing a class with this syntax and I kept mistyping it because
it's fugly". Or perhaps not, but at least it is vastly lower effort
to do. The Async people are already doing this, which is very
good! All we need is make that easier and more automated to do for
any RFC.

I believe the "official"[^1] Docker PHP images provide builds of every
RC version of PHP. It might be interesting for them to provide
php-unstable variants that are builds of specific feature branches, much
like 3v4l does. Doing so would be up to that community,[^2] though—not
this one.

Cheers,
Ben

[^1]: They are officially maintained and supported by the Docker
Community, not by Docker or the PHP project.
[^2]: https://github.com/docker-library/php

1 month ago by Ben Ramsey — view source — reply

unread

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

A feature that ships in PHP is the responsibility of the core
maintainers, regardless of who "owns" the feature. Ultimately, it all
comes down to trust, and if PHP ships an insecure feature, the core
maintainers can't shrug and point to the feature owners and say, "It's
not our fault."

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.

One of the most used programming languages in the world is also one of
the most underfunded programming languages in the world. You're
overestimating donations to the PHP Foundation. This is why, in the
recent search for a new executive director, we emphasized the importance
of hiring someone who we think will be able to increase donations. I'm
really excited about the future of the foundation, and when it has a
stable pool of donors, maybe this conversation will be very different.

The finances for the PHP Foundation are public:
https://opencollective.com/phpfoundation#category-BUDGET

If you look at expenses paid for the past year compared to contributions
collected, you'll note the foundation has spent $100k more than it has
collected. This is possible due to some large one-time donations by
corporate sponsors, but it's not sustainable.

We can change this. Convince companies who use PHP to commit to
recurring donations. Once it has a sustainable revenue and is able to
hire more than 10 full-time and part-time developers, maybe it will be
able to fund projects like this.

Cheers,
Ben

1 month ago by Daniil Gentili — view source — reply

unread

We can change this. Convince companies who use PHP to commit to
recurring donations. Once it has a sustainable revenue and is able to
hire more than 10 full-time and part-time developers, maybe it will be
able to fund projects like this.

You cannot convince companies who are actively looking for alternatives to
PHP due to the lack of core, modern features like async, generics to invest
in PHP, so that maybe (more likely no than yes, as proven) in the future
internals may accept RFCs (financed by the PHPF or not), bringing async and
generics into PHP.

You first need to have a working, proven track record of leadership capable
of merging new features into PHP.

Internals currently has exactly the opposite track record: this has to
change in order for both PHP and the PHPF to succeed.

1 month ago by Jakub Zelenka — view source — reply

unread

Hi,

On Sat, Mar 14, 2026 at 7:34 PM Daniil Gentili daniil.gentili@gmail.com
wrote:

Hello internals,

Submitting for discussion the php-community RFC, for a faster-moving,
community-driven PHP: https://wiki.php.net/rfc/php-community

There is one important thing to note. To make anything of this applicable,
you would need to create / update existing policies in
https://github.com/php/policies . But I guess you might just keep it as it
is and note that if this passes, follow up RFC for policy update will be
done. Otherwise it might be waste of your time to create all those policies
if it gets rejected.

Kind regards

Jakub