On 15/03/2026 12:20, Daniil Gentili wrote:
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:
1) allow users to test far-reaching, experimental, changes to the
language and engine
2) 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]
