Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:82552 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 48025 invoked from network); 12 Feb 2015 20:02:37 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Feb 2015 20:02:37 -0000 Authentication-Results: pb1.pair.com header.from=anatol.php@belski.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=anatol.php@belski.net; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error) X-PHP-List-Original-Sender: anatol.php@belski.net X-Host-Fingerprint: 85.214.73.107 klapt.com Received: from [85.214.73.107] ([85.214.73.107:53219] helo=h1123647.serverkompetenz.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A8/80-45232-BD60DD45 for ; Thu, 12 Feb 2015 15:02:36 -0500 Received: by h1123647.serverkompetenz.net (Postfix, from userid 33) id DFDB523D6002; Thu, 12 Feb 2015 21:02:32 +0100 (CET) Received: from 217.254.133.96 (SquirrelMail authenticated user anatol@belski.net) by webmail.klapt.com with HTTP; Thu, 12 Feb 2015 21:02:32 +0100 Message-ID: <59b0695a30efa0f4b1a2e197c9d5dc4e.squirrel@webmail.klapt.com> In-Reply-To: <54DB3184.8080408@seld.be> References: <54DB3184.8080408@seld.be> Date: Thu, 12 Feb 2015 21:02:32 +0100 To: "Jordi Boggiano" Cc: internals@lists.php.net User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC][VOTE][RESULT] Removal of dead or not yet PHP7 ported SAPIs and extensions From: anatol.php@belski.net ("Anatol Belski") Hi Jordi, On Wed, February 11, 2015 11:40, Jordi Boggiano 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. > that was not suggested yet. IMHO the idea is healthy at least for imap and mcrypt. I also think the most reasons to vote for the non removal was the lack on alternatives as well, not just because the dependencies are unsupported. And another RFC were needed for this, obviously. I'm not disposed for yet another one ATM, but that doesn't mean only me could do that. Regards Anatol