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

>>> 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). Strict removal conditions and bundling of multiple versions into a single php-community build are there precisely to allow thought-free adoption of feature extensions, without being afraid of suddenly losing access to them or encountering breaking changes. > >>> 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. Note, fixes to feature extensions due to breaking changes to internal PHP APIs will be handled by whoever is making the breaking changes, not by the feature owners (like with Linux). Regards, Daniil Gentili.