On Fri, Feb 13, 2015 at 3:51 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > Hi all, > > On Wed, Feb 11, 2015 at 8:20 PM, Andrey Andreev <n...@devilix.net> wrote: > >> On Wed, Feb 11, 2015 at 12:40 PM, Jordi Boggiano <j.boggi...@seld.be> >> wrote: >> > On 09/02/2015 22:29, Anatol Belski wrote: >> >> >> >> ext/imap >> >> ext/mcrypt >> >> ext/pdo_dblib >> > >> > >> > Sorry if this was suggested already but if those are not maintained much >> and >> > should not be used further ideally, shouldn't we add E_DEPRECATED to >> them at >> > least? >> > >> > I understand that they are kept to avoid making the upgrade path harsher, >> > but it's also not great to let they linger on forever with no notice to >> > users that they are doing something wrong. >> > >> >> I don't think it has been suggested already, but I agree - should be >> deprecated. > > > > Vote is vote. Why don't we deprecate them by documentation with obvious > warning? > We cannot deprecate them immediately, anyway. > > Is there any objection for deprecation by document?
So we do not want to kill them because they are still used (but dead). But we may come with some wrapper to replace almost all the features provided by the dead libs? At least for mcrypt, good luck to anyone willing to do that for imap ;). But now we should deprecate them but deprecation has lost its meaning as we vote on the actual removal, which may be rejected. So basically, unless we clearly have no chance to have a replacement, I am totally against adding yet some deprecation notices, not if adding a deprecation is actually followed by a removal, read: Vote for deprecation means removal in next. But if it is not the case and we keep deprecated features forever, then we may just kill the deprecation flag instead. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
