Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62936
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.163 as permitted sender)
Message-ID: <504E72E2.9040100@sugarcrm.com>
Date: Mon, 10 Sep 2012 16:08:18 -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: jpauli <jpauli@php.net>
CC: PHP Internals <internals@lists.php.net>
References: <CAMUwpuRdHMmbYSj1nqbKSdV=23SA20J0udaU-CYmHBRbZ40NeQ@mail.gmail.com>
In-Reply-To: <CAMUwpuRdHMmbYSj1nqbKSdV=23SA20J0udaU-CYmHBRbZ40NeQ@mail.gmail.com>
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!

> Based on our recent discussion on #pecl , I'd like we clarify what we
> think is a "BCB" (Backward Compatibility Break) as well as what "only
> minor BC breaks" could mean.
> Stas' recent topic on internals "On BC and interfaces" may serve as a
> reflection basis.
> As our release process told us that we should not add BCB (but only
> "minor" ones ... hum) in any minor release (nor revision), and as 5.5
> release process is going to start soon, I'd like we try to all agree
> on that point.

I think first we have to distinguish several levels of BC:

1. Binary BC
2. Source-level extension BC
3. PHP Code (API) BC

Binary BC means that extension compiled with one version would work with
another without recompilation. We keep this level of compatibility
through all minor (5.x) releases and breaking it is an absolute no-no.
However, between minors (5.5 -> 5.5) breaking it is fine.

Source-level extension BC means that an extension may be successfully
compiled and working in two versions. We strive to keep it between
minors, though if absolutely necessary for implementing new stuff we may
occasionally break it. But this has to be kept to absolute minimum and
only done if there's absolutely no way to avoid it - e.g., if we
refactoring the engine to use more efficient way to generate opcodes and
we need to change zend_op_array structure, some extensions that use it
may be broken.

PHP Code BC means that a PHP script that works in one version also works
in another version. We should keep this level of BC across all major
version, and breaking it between minor versions is not acceptable. Only
exceptions may be: introduction of new keywords (may break code that
uses the same identifier), security fixes (if we have to introduce more
secure way of doing something, application using insecure practices may
be broken), bug fixes (if application relied on a buggy behavior of PHP
to work, it may be broken), removal of already deprecated features.

Adding new functions usually not considered BC break, though technically
it may break code that used the same function name.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227