On Friday, 30 August 2024 at 20:13, Christoph M. Becker <cmbecke...@gmx.de> wrote:
> On 30.08.2024 at 19:05, Jim Winstead wrote: > > > Perhaps if the effort from the PHP Foundation to build a next-generation > > PECL bears fruit, an even harder look can be taken at migrating out even > > more of the extensions still living in the php-src tree. With some robust > > CI, care could be made to make sure changes in php-src that impact > > extensions is noticed and dealt with, but spinning them out on their own > > might make them easier for more people to contribute to and maintain. > > > Let's see what happened with the latest unbundled extensions: > > * PHP 7.4 unbundled ext/wddx, ext/recode and ext/interbase; neither has > any release on PECL; they are effectively dead. At least the latter is > still barely maintained outside of PECL. > > * PHP 8.0 unbundled ext/xmlrpc, which had three releases, and given that > I'm listed as maintainer, I'd say that extension is also dead. > > * PHP 8.4 unbundled imap and pspell. These had two releases each, but I > wouldn't hold my breath for a third. > > * PHP 8.4 also unbundled oci8 and pdo_oci. The former has already been > partially maintained on PECL. Regarding the latter Christoph Jones is > struggling to keep it somewhat maintained (due to lack of time). > > And generally, while there are many well maintained extensions on PECL, > most (i.e. way more than half of the extension there) are outright > abandoned, dead or half-dead, a lot of the latter barely kept alive by > Remi Collet. A next generation PECL (installer) will not change this; > only people who actively care about these extension could, if these > people have knowledge of PHP extension development. > > I'm not saying that all PECL extensions deserve to be kept alive; there > are good reasons for many to have been abandoned, e.g. because they were > built on no longer supported libraries, are generally not useful > anymore, or would be written in PHP nowadays (e.g. ext/dbase). > > Instead I'm saying that we should be careful to unbundle extensions. > This should probably seen as a last resort if we absolutely can't > maintain the extension any longer, or it doesn't make sense to do that. > I'm not sure yet that ext/snmp falls into this category. > > It's easy to vote "yes, unbundle this extension" if you've never used > the extension and are not planning to do so in the future. It may be a > death sentence, though. > > Christoph Arguably this is because PECL is a pain to use as a maintainer and that we use PECL as a "graveyard". But it is my biggest belief that most extensions would be better outside the php-src repo and live in PECL so they could be updated independently and not tied to the yearly PHP release schedule. The fact that ext/cURL is not allowed to be updated in patch releases any more means that features in libcurl take *ageees* to get exposed in PHP. It also prevents extensions to be properly refactored because they are bound to the same BC policy as the PHP engine, which doesn't make a lot of sense to me. I could have cleaned-up ext/xml with all the weird "string method callables" used with xml_set_object() in 1 week by releasing 3 different versions on PECL, instead of performing some refactoring and 1 RFCs. [1] Or fix ext/dba and do a release without the absurd parameter type of dba_key_split(). Having the DOM extension in PECL and be able to just change the behaviour of the legacy classes to fix them instead of creating a whole new hierarchy which slows down adoption could also have been prevented (if it is a good idea) if it wasn't tied to PHP's release schedule and BC policy. It would also permit extensions to follow semver while the engine continues to have its own versioning system. Having an extension be "bundled" doesn't even mean it is properly maintained, as neither ext/imap, ext/xmlrpc, or in this case ext/snmp are actually maintained. Having added support for PIE for ext/csv, which was very easy, [2] I hope when this tool is finally ready, and we ditch PECL, we will start unbundling extensions so that they are not constrained by the PHP Engine release cycle. Best regards, Gina P. Banyard [1] https://wiki.php.net/rfc/deprecations_php_8_4#xml_set_object_and_xml_set_handler_with_string_method_names [2] https://gitlab.com/Girgias/csv-php-extension/-/commit/ab978521e4d3bde15b73838d4605c5e5178ba082
