Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130328
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FACAC0ED-B1B1-43E8-9EC0-7E7668CA07BB"
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
Subject: [PHP-DEV] Re: [RFC] php-community: a faster-moving, community-driven PHP.
Date: Sun, 15 Mar 2026 12:54:25 +0100
References: <839153A0-004D-4562-BD6E-65923201EDAA@gmail.com>
To: internals@lists.php.net
In-Reply-To: <839153A0-004D-4562-BD6E-65923201EDAA@gmail.com>
Message-ID: <EBF876EE-BB71-48A0-B3E2-B84FAF7A443C@gmail.com>
From: daniil.gentili@gmail.com (Daniil Gentili)


--Apple-Mail=_FACAC0ED-B1B1-43E8-9EC0-7E7668CA07BB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Bumped the RFC with some clarifications based on the arguments presented =
here and elsewhere.


### Changelog

#### 1.0.1

- **New section: [Sandboxing](#sandboxing)** =E2=80=94 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. =20

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. =20

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. =20

- **New section: [Requirements to succeed](#requirements-to-succeed)**

In order for `php-community` to succeed at its goal of making =
experimental features more accessible, major frameworks and libraries =
need to start relying on features initially only present in =
`php-community`.

For this purpose, most new PHP features should get proposed to =
`php-community` first, instead of normal PHP, in order to speed up =
adoption of both those features and of `php-community` itself.

In fact, the normal RFC process could also be altered to **require** all =
new features to pass through community RFCs, first.

To further increase adoption, the PHP Feature Extensions API may also be =
offered on normal PHP versions, either for especially mature feature =
extensions to get even more adoption data, or for all feature =
extensions, perhaps even skipping the separate `php-community` distro =
altogether (though some of its properties like a stable release schedule =
not movable by security updates are still preferred).

- **Voting (clarification)** =E2=80=94 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. =20

- **Community RFC owners (clarifications)**


Crucially, the maintenance burden of feature extensions will lay =
**exclusively** on the feature owners, not `php-src` maintainers. =20

Features and bug fixes for feature extensions will **NOT** be a =
responsibility
of `php-src` maintainers. =20

This also includes reviews on feature extension code, which will be a =
responsibility mainly of the owners of said features. =20

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. =20

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). =20

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. =20

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. =20

- **Removal of community RFC features (clarification)** =E2=80=94 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. =20

- **Release process (clarifications)** =E2=80=94 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. =20

- **Feature extensions (clarification)** =E2=80=94 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. =20

- **API (clarification)** =E2=80=94 The `PhpFeature` API (and eventually =
even feature extensions) could be made available in normal PHP for =
forward compatibility. =20


> On 14 Mar 2026, at 19:32, Daniil Gentili <daniil.gentili@gmail.com> =
wrote:
>=20
>=20
> Hello internals,
>=20
> Submitting for discussion the php-community RFC, for a faster-moving, =
community-driven PHP: https://wiki.php.net/rfc/php-community
>=20
> 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.=20
>=20
> As anticipated by Edmond Dantes in an earlier thread, I'm now part of =
the True Async committee.
>=20
> 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.
>=20
> True Async is one of, but not the only nor the main reason why I =
created this RFC.=20
>=20
> 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.
>=20
> I believe PHP truly deserves this.
>=20
> Kind regards,
> Daniil Gentili.
>=20
> =E2=80=94
>=20
> Daniil Gentili - Senior software artisan
> Website: https://daniil.it <https://daniil.it/>
> GitHub: https://github.com/danog
> Email: daniil@daniil.it


--Apple-Mail=_FACAC0ED-B1B1-43E8-9EC0-7E7668CA07BB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
content=3D"text/html; charset=3Dutf-8"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;">Bumped the RFC with some clarifications =
based on the arguments presented here and =
elsewhere.<div><br></div><div><div><br></div><div>### =
Changelog</div><div><br></div><div>#### 1.0.1</div><div><br></div><div>- =
**New section: [Sandboxing](#sandboxing)** =E2=80=94 Moved sandboxing =
content into its own dedicated =
section.</div><div><br></div><div>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. &nbsp;</div><div><br></div><div>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. &nbsp;</div><div><br></div><div>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. =
&nbsp;</div><div><br></div><div>- **New section: [Requirements to =
succeed](#requirements-to-succeed)**</div><div><br></div><div>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`.</div><div><br></div><div>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.</div><div><br></div><div>In fact, the normal RFC =
process could also be altered to **require** all new features to pass =
through community RFCs, first.</div><div><br></div><div>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).</div><div><br></div><div>- **Voting =
(clarification)** =E2=80=94 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. =
&nbsp;</div><div><br></div><div>- **Community RFC owners =
(clarifications)**</div><div><br></div><div><br></div><div>Crucially, =
the maintenance burden of feature extensions will lay **exclusively** on =
the feature owners, not `php-src` maintainers. =
&nbsp;</div><div><br></div><div>Features and bug fixes for feature =
extensions will **NOT** be a responsibility</div><div>of `php-src` =
maintainers. &nbsp;</div><div><br></div><div>This also includes reviews =
on feature extension code, which will be a responsibility mainly of the =
owners of said features. &nbsp;</div><div><br></div><div>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. =
&nbsp;</div><div><br></div><div>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). =
&nbsp;</div><div><br></div><div>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. &nbsp;</div><div><br></div><div>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. &nbsp;</div><div><br></div><div>- **Removal of community RFC =
features (clarification)** =E2=80=94 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. =
&nbsp;</div><div><br></div><div>- **Release process (clarifications)** =
=E2=80=94 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. &nbsp;</div><div><br></div><div>- **Feature extensions =
(clarification)** =E2=80=94 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. &nbsp;</div><div><br></div><div>- **API =
(clarification)** =E2=80=94 The `PhpFeature` API (and eventually even =
feature extensions) could be made available in normal PHP for forward =
compatibility. &nbsp;</div><div><br =
id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote =
type=3D"cite"><div>On 14 Mar 2026, at 19:32, Daniil Gentili =
&lt;daniil.gentili@gmail.com&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div><meta http-equiv=3D"content-type"=
 content=3D"text/html; charset=3Dutf-8"><div style=3D"overflow-wrap: =
break-word; -webkit-nbsp-mode: space; line-break: =
after-white-space;"><br>
Hello internals,<div><br></div><div>Submitting for discussion the =
php-community RFC, for&nbsp;a faster-moving, community-driven =
PHP:&nbsp;https://wiki.php.net/rfc/php-community</div><div><br></div><div>=
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.&nbsp;</div><div><br></div><div>As anticipated by Edmond Dantes =
in an earlier thread, I'm now part of the True Async =
committee.</div><div><br></div><div>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.</div><div><br></div><div>True Async is one of, but not the only nor =
the main reason why I created this RFC.&nbsp;</div><div><br></div><div>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.</div><div><br></div><div>I believe PHP =
truly deserves this.</div><div><br></div><div>Kind =
regards,</div><div>Daniil =
Gentili.</div><div><br></div><div>=E2=80=94</div><div><br></div><div>Danii=
l Gentili - Senior software artisan</div><div>Website: <a =
href=3D"https://daniil.it/">https://daniil.it</a></div><div>GitHub: <a =
href=3D"https://github.com/danog">https://github.com/danog</a></div><div>E=
mail: =
daniil@daniil.it</div></div></div></blockquote></div><br></div></div></bod=
y></html>=

--Apple-Mail=_FACAC0ED-B1B1-43E8-9EC0-7E7668CA07BB--