Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:65294 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 83691 invoked from network); 28 Jan 2013 19:41:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Jan 2013 19:41:31 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.143 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.143 smtp143.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.143] ([67.192.241.143:50094] helo=smtp143.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 83/CA-28517-A64D6015 for ; Mon, 28 Jan 2013 14:41:31 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 0192B1801C2; Mon, 28 Jan 2013 14:41:27 -0500 (EST) X-Virus-Scanned: OK Received: by smtp24.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 8D24B18006A; Mon, 28 Jan 2013 14:41:27 -0500 (EST) Message-ID: <5106D468.1050006@sugarcrm.com> Date: Mon, 28 Jan 2013 11:41:28 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Pierre Joye CC: Gustavo Lopes , Zeev Suraski , Alan Knowles , PHP Internals References: <1460659e-237d-4c7c-8cfa-523ec857d646@email.android.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [VOTE] Deprecate and remove calls from incompatible context From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > If we introduced BC breaks other than those, then we'd to review them > and see why they have been introduced. But one thing is clear: we do > not allow BC breaks between 5.x and 5.x+1. We need a better definition of BC break then. Is deprecating an existing feature BC break? Is adding a notice BC break? If something like making isset($string["foo"]) not return true anymore or fixing 64-bit numbers handling BC break? Each can break code that relied on old way of doing things. If we ban all of them for 5.x we'd need to have 6.0 much sooner, since otherwise we'd be stuck with a lot of old unfixable warts for 5 years. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227