Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130334
Precedence: list
MIME-Version: 1.0
References: <839153A0-004D-4562-BD6E-65923201EDAA@gmail.com>
 <2DE0046C-8BAD-4459-B65D-712D7628093B@gmail.com> <QS6VsjCKREeCSH-PRMGGkK1j2pEEf9BNOm-tjZZIYIa0_XKqiwO01y5E_h6Ijb0BueVzJ8OS5qYsxs8gtt9wImUmAf0epG-yoi95W6VzN3U=@chstudio.fr>
In-Reply-To: <QS6VsjCKREeCSH-PRMGGkK1j2pEEf9BNOm-tjZZIYIa0_XKqiwO01y5E_h6Ijb0BueVzJ8OS5qYsxs8gtt9wImUmAf0epG-yoi95W6VzN3U=@chstudio.fr>
Date: Sun, 15 Mar 2026 14:45:07 +0100
Message-ID: <CAKXKfQuf5XsWbjEu=GHZ2ZDAgqUMMhv8Ne=8ioTTy1m23iF0yQ@mail.gmail.com>
Subject: Re: [PHP-DEV] Re: [RFC] php-community: a faster-moving,
 community-driven PHP.
To: =?UTF-8?Q?St=C3=A9phane_Hulard_=2D_CH_Studio?= <s.hulard@chstudio.fr>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000150a59064d1050fa"
From: daniil.gentili@gmail.com (Daniil Gentili)

--000000000000150a59064d1050fa
Content-Type: text/plain; charset="UTF-8"

>
> 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.


>
>
>
>
>

--000000000000150a59064d1050fa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">Also I&#39;m afraid that if we have a lot of different features in th=
e progress that will create a crazy possible combination matrix. How to ens=
ure everything behave correctly with all the others, or only some of them i=
nside the community version?<br></blockquote></div></div><div dir=3D"auto">=
<br></div><div dir=3D"auto">In the same way projects handle different versi=
ons of libraries, through requires and conflicts declarations.</div><div di=
r=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><br>
So I don&#39;t understand why we need the php-community version if it conta=
ins &quot;only preinstalled&quot; extensions that users can experiment them=
selves. Maybe it can allow verifying adoption but that means users that wil=
l switch to the community version for a daily usage and it&#39;ll split the=
 user base.<br>
<br>
However I think deeper features and experiments are important. I think that=
 extension can&#39;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 a=
nd changes?<br>
<br>
I think it can simplify this RFC by having a complete separation between th=
e engine, stable and production ready and the experiments (which can stay e=
xtensions).<br>
<br>
With PIE it&#39;s now easier to install extensions and also test them. <br>
<br>
<br>
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 pa=
st (maintainers can still maintain the core part).<br></blockquote></div></=
div><div dir=3D"auto"><br></div><div dir=3D"auto">The point is not to setup=
 scaffolding in PHP for feature extensions.</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">The point is to bundle experimental extensions into PHP=
 (even normal PHP), in order to speed up adoption across the entire ecosyst=
em, including shared hosts.</div><div dir=3D"auto"><br></div><div dir=3D"au=
to"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><br></blockquote><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><b=
r></blockquote></div></div></div>

--000000000000150a59064d1050fa--