>>> 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.
