Hi Peter Den søn. 24. mar. 2019 kl. 14.39 skrev Peter Kokot <peterko...@gmail.com>: > I'm all in for helping out here with both users using this and > maintainers that need to worry about if this extension is even working > ok. However, just one quick thought. The deprecation usually means > that some functionality will cease to exist. And users usually expect > and consider removing deprecated usage from their code and move to > something else. Not that they will have an option to install it over > PECL in PHP 8.0... Is this ok approach for this case? Because with > this approach PHP is also saying quietly that PECL is a museum for > extensions and not a place for developing them further. I might be > completely wrong here though...
I opted for the deprecation warning as the functionality will effectively cease to exist in php-src, we have done similar things to other extensions (recently ext/wddx) or even ext/mysql (which did have the ext/mysqli and ext/pdo_mysql) as alternatives, similar ext/interbase have the ext/pdo_firebird alternative. I see the following options to go about this extension: 1) Add a deprecation warning as the functionality will effective cease to exist in php-src. We don't know if this extension will be taken over if it ends up in PECL, so this is the safe bet, which is why I opted for this initially in the RFC 2) Silently remove it already in 7.4, this is also a very viable option, but it does not give the users to think about alternatives, We did this for some extension in 5.6 -> 7.0, like ext/mssql. If we go with this option, it means that there is no warnings and that whoever picks up the extension (if any) can give them a warning free environment. I can amend the RFC to have these voting choices in mind if it is preferable, similar to ext/wddx. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
