Am 05.06.2011 12:57, schrieb Pierre Joye: > The last point is that pecl allows a much more flexible release > management than the core will even do.
in theory > So instead of doing some marketing/communication actions by bundling some > known extensions, we should better promote pecl better. not promote - MAINTAIN it better! in fact most of PECL-extensions are a lucky game since linux distributors has to find workarounds for rarely maintained extensions and you can not be sure that a extension can be compiled after a update of php or some system-library and only if you have luck a maintainer answers on a bug-report _____________________ http://pecl.php.net/package/GDChart dead, no longer maintained and it needed a message to this list to get this confirmed by Ilia Alshanetsky, WTF - why is there no big red hint "DO NOT USE IT" until now? http://pecl.php.net/package/geoip - stable 2009-03-11 what about try if this works after new releases of the library behind - with recent GeoIP-Versions php crashs if "geoip_db_get_all_info" is called, and sorry but after more than 2 years it is not the users hob reporting everything necause lazy maintainers writing code once and orphaning it http://pecl.php.net/package/pecl_http/2.0.0dev1 coll, in th emiddle of 5.3 lifecycle a total incompatible reqrite is started and hopefully no one has projects relying on the pecl-extension http://pecl.php.net/package/ssh2 was three years not maintained and could not compiled with recent versions of libssh2 without some magic patches from distributors http://pecl.php.net/package/gnupg did not work for threee years on fedora-systems no anwser on bu-reports - so what do you do in such a case? and you will tell us PECL is a relieable source for components anybody is using in his projetcs? not really!
signature.asc
Description: OpenPGP digital signature
