Re: [RFC] php-community: a faster-moving, community-driven PHP.

Am 15.03.2026 um 11:33 schrieb Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk>: >> A feature is eligible for removal only if both of the following conditions are met: >> - It has no active maintainer listed in the accepted community RFC design document. >> - Adoption is negligible, as evidenced by Packagist statistics. > > This feels incompatible with the rest of the process. If features are easy to propose, release, > and iterate, it should be just as easy to mark them abandoned or obsolete. Otherwise, an interesting > but flawed feature has to be maintained forever even if its author loses interest - and who is going > to do that maintenance? > > If the intention of these features is to be experimental, perhaps every feature version could > have a fixed lifetime. Users know that they can't rely on it long-term, but if it's > popular it will hopefully make it into a stable release of PHP. I was thinking along the same lines but it also made me wonder: Who would target such an unstable community version for production? I know that I'd think more than twice before relying on any feature which might disappear or change again soon(ish). >> php-community will always be based on the latest stable PHP release > > Who will be responsible for merging changes made to "feature extensions" back to > master, and stabilising the first community release after a new stable release? What about the other way around: It is assumed that the extension maintainers fix conflicts with changes in the stable php release, right? As an extension maintainer and hence responsible I'd be worried about this, especially as changes to stable could be completely incompatible with my extension. Which could hurt users of my extension and therefore myself. Regards, - Chris