Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:78829 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 90066 invoked from network); 7 Nov 2014 00:43:54 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Nov 2014 00:43:54 -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 108.166.43.67 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.67 smtp67.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.67] ([108.166.43.67:42746] helo=smtp67.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F4/00-24315-7C51C545 for ; Thu, 06 Nov 2014 19:43:52 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 3174638042F; Thu, 6 Nov 2014 19:43:49 -0500 (EST) X-Virus-Scanned: OK Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id D787B380213; Thu, 6 Nov 2014 19:43:48 -0500 (EST) X-Sender-Id: smalyshev@sugarcrm.com Received: from Stass-MacBook-Pro.local ([UNAVAILABLE]. [74.85.23.222]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.3.2); Fri, 07 Nov 2014 00:43:49 GMT Message-ID: <545C15C4.1080503@sugarcrm.com> Date: Thu, 06 Nov 2014 16:43:48 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Florian Margaine , PHP Internals References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Thresholds of backwards compatibility breaks From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > - major BC break: major versions only. 5 major BC breaks allowed per major > version. I'm not sure how such numbers make sense. Why 5 and not 3 or 7 or 17? If that breaks your code, even one is too much. If your code is not affected, why would you care if it's 5 or 15 or 150? I'm afraid this would just devolve into semantics discussion and arguments about how to count them and why it can be 5 but not 6. I don't see any reason to put any numeric value on it. > - minor BC break: > - minor versions: 5 minor BC breaks allowed. > - patch versions: 1 BC break allowed. Patch & minors should not have BC breaks, excepting bugfixes where it is inevitable. Of course, it is an ideal situation, and in practice we may miss stuff, or we may not have a choice, or we may prefer BC break to the alternative. But again I don't see how putting a number on it helps something. If we have two cases where we must have BC break and not one - and we absolutely sure we have no better choice and that's what we have to do - how having arbitrary limit of 1 would help? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/