Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130315
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.400.21\))
Subject: Re: [PHP-DEV] [RFC] php-community: a faster-moving, community-driven
 PHP.
Date: Sun, 15 Mar 2026 00:59:24 +0100
References: <839153A0-004D-4562-BD6E-65923201EDAA@gmail.com>
 <166C02DA-50BC-4283-86F9-18AD7A49E2C1@cschneid.com>
To: internals@lists.php.net
In-Reply-To: <166C02DA-50BC-4283-86F9-18AD7A49E2C1@cschneid.com>
Message-ID: <670593F4-00F1-429D-868E-F15E3688F3FA@gmail.com>
From: daniil.gentili@gmail.com (Daniil Gentili)


>=20
> 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
>=20
> 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=E2=80=99d still leave =
it exposed even if just for PR reasons.

>=20
> 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.
>=20

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.