Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130333
Date: Sun, 15 Mar 2026 13:01:45 +0000
To: Daniil Gentili <daniil.gentili@gmail.com>
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [RFC] php-community: a faster-moving, community-driven PHP.
Message-ID: <QS6VsjCKREeCSH-PRMGGkK1j2pEEf9BNOm-tjZZIYIa0_XKqiwO01y5E_h6Ijb0BueVzJ8OS5qYsxs8gtt9wImUmAf0epG-yoi95W6VzN3U=@chstudio.fr>
In-Reply-To: <2DE0046C-8BAD-4459-B65D-712D7628093B@gmail.com>
References: <839153A0-004D-4562-BD6E-65923201EDAA@gmail.com> <2DE0046C-8BAD-4459-B65D-712D7628093B@gmail.com>
Feedback-ID: 41282912:user:proton
Precedence: list
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="------d61201ce867a104b5d9fc18fe386e06f3f1965dad1fa5232439274c5f4b3a884"; charset=utf-8
From: s.hulard@chstudio.fr (=?utf-8?Q?St=C3=A9phane_Hulard_-_CH_Studio?=)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------d61201ce867a104b5d9fc18fe386e06f3f1965dad1fa5232439274c5f4b3a884
Content-Type: multipart/mixed;boundary=---------------------7c515047e16bf7f92650b0e758b388d6

-----------------------7c515047e16bf7f92650b0e758b388d6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

Hello !

Le dimanche 15 mars 2026 =C3=A0 13:44, Daniil Gentili <daniil.gentili@gmai=
l.com> a =C3=A9crit=C2=A0:

> In other words, feature extensions are "guests" allowed into the php-com=
munity branch, or PIE extensions "pre-installed" into PHP, and are develop=
ed and maintained exclusively by their owners just as if they were a stand=
alone extension, with some overview from `php-src` maintainers, yet mainta=
ining independence on design/API choices (again, as if they were standalon=
e 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 maintainer=
s
* Extensions can interact with PHP core without adding work for the curren=
t 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 progres=
s that will create a crazy possible combination matrix. How to ensure ever=
ything behave correctly with all the others, or only some of them inside t=
he 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. Mayb=
e 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 tha=
t extension can't completely change PHP behavior today, extensions might o=
nly have access to specific part of the engine lifecycle. Maybe it can be =
interesting to add more hooks so extensions can leverage deeper features a=
nd changes?

I think it can simplify this RFC by having a complete separation between t=
he 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=C3=A9phane

---
St=C3=A9phane Hulard
https://chstudio.fr
-----------------------7c515047e16bf7f92650b0e758b388d6
Content-Type: application/pgp-keys; filename="publickey - s.hulard@chstudio.fr - 0x01B6678A.asc"; name="publickey - s.hulard@chstudio.fr - 0x01B6678A.asc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="publickey - s.hulard@chstudio.fr - 0x01B6678A.asc"; name="publickey - s.hulard@chstudio.fr - 0x01B6678A.asc"

LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWWJDVWZSWUpLd1lCQkFI
YVJ3OEJBUWRBRE1xZnZRYzM4Z21sbWhDSVR2cFAyUVlmYVN4ZEZRT2YKb3NTNXJ6RGhNTTdOSzNN
dWFIVnNZWEprUUdOb2MzUjFaR2x2TG1aeUlEeHpMbWgxYkdGeVpFQmphSE4wCmRXUnBieTVtY2o3
Q2p3UVFGZ29BSUFVQ1liQ1VmUVlMQ1FjSUF3SUVGUWdLQWdRV0FnRUFBaGtCQWhzRApBaDRCQUNF
SkVGQUZhbVNYeXFiakZpRUVBYlpuaXQ1Y1gyZHNma1lSVUFWcVpKZktwdU02cGdEL1Q5SFQKK1B0
V1FXQ25mVU9FVFJzem02WnJjTk9MSnF0NWJmSll6TXRLcWNVQkFNanZGTVQ0NnBxd1VvWlFrNkR1
CnN5MU5ua2VObjJObnVyOW1tcGpiZTU0R3pqZ0VZYkNVZlJJS0t3WUJCQUdYVlFFRkFRRUhRRUJt
WGVSdgpHSXc1UldCRmxZN2YyN3RBemNUeGt0UDdEWTc1NGYvV1ozd0dBd0VJQjhKNEJCZ1dDQUFK
QlFKaHNKUjkKQWhzTUFDRUpFRkFGYW1TWHlxYmpGaUVFQWJabml0NWNYMmRzZmtZUlVBVnFaSmZL
cHVONUp3RDdCQmVzCnkzYnNVSWg4T1lsRUsrS0FBYkNtT3h5QnJ3UzdKQkpJaU9BeElJb0EvMVFY
UlphNUdoS1k1RnBrb1I5RQpPWndCWHY3ZXNlOGt4TTdGT2hIMlhFWUIKPUVOTGYKLS0tLS1FTkQg
UEdQIFBVQkxJQyBLRVkgQkxPQ0stLS0tLQo=
-----------------------7c515047e16bf7f92650b0e758b388d6--

--------d61201ce867a104b5d9fc18fe386e06f3f1965dad1fa5232439274c5f4b3a884
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0Fgmm2raoJEFAFamSXyqbjRRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmf9oXL7mIqUhdNPYKKhk4EWFITrMcLunBROMzWV
y2xc+xYhBAG2Z4reXF9nbH5GEVAFamSXyqbjAABTZQD/RUfOKvwbKXN7ZYN+
kqEAN3pdDJjwuaqT0sTCVCUZQrEA/i7Kz/4GUO04sffnfYMZ3unXdf/UTEPf
QxSsRgycyXsP
=RlM+
-----END PGP SIGNATURE-----


--------d61201ce867a104b5d9fc18fe386e06f3f1965dad1fa5232439274c5f4b3a884--