Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:62935 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 13905 invoked from network); 10 Sep 2012 23:08:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Sep 2012 23:08:14 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.163 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.163 smtp163.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.163] ([67.192.241.163:56192] helo=smtp163.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 95/23-26944-CD27E405 for ; Mon, 10 Sep 2012 19:08:13 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp26.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 1AF0E801A2; Mon, 10 Sep 2012 19:08:10 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp26.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 48D0780138; Mon, 10 Sep 2012 19:08:09 -0400 (EDT) Message-ID: <504E72D8.2070700@sugarcrm.com> Date: Mon, 10 Sep 2012 16:08:08 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Pierre Joye CC: jpauli , PHP Internals References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] What is our definition of a "Backward Compatibility Break" From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > That's more about internals APIs, which is not what is meant in the > release RFCs for x.y+1 releases. The idea though wasn't about internals APIs. The idea was that for users it's better to have platform that they can expect to work with their code 10 years after than to have a platform that you have to rewrite your code each couple of years. PHP wasn't excellent about it in the past, though there were very good reasons for that. But we need to start thinking about how we can get it much better in the future. Including thinking along the ways that each feature we add today will be set in stone for next 10 years - so we better think 10 years or more ahead when we do them. I know it's not easy and sometimes may be just impossible to know that far in advance, but we should try to do our best. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227