Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70210
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.171 as permitted sender)
MIME-Version: 1.0
Date: Tue, 19 Nov 2013 20:16:03 +0100
Message-ID: <CAF+90c_zyAr7kRnY9FArehhJ-QUxA-6B4TqNUx2Bzxwumbr1zA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0149ca10e621cf04eb8c7ed2
Subject: Making "backwards compatibility" discussions more constructive
From: nikita.ppv@gmail.com (Nikita Popov)

--089e0149ca10e621cf04eb8c7ed2
Content-Type: text/plain; charset=ISO-8859-1

Hi internals!

In a lot of the recent discussions (e.g. the HTTP_RAW_POST_DATA one) I've
seen the "we can't break backwards compatibility in PHP 5.x.y" argument
crop up again and again.

This rather unfortunate formulation takes root in the releaseprocess RFC
[1] and drives all discussions of BC issues into a non-constructive
direction.

Fact is that nearly all changes (by being changes...) break backwards
compatibility to some degree [2] and we *do* most certainly allow them in
both minor and bugfix releases. Whether they are allowed (and for what
version) depends on the *severity* (rather than existence) of the breakage.

I would really appreciate it if we could move BC-related discussions away
from "Does it break BC?" (Yes, it does, in some way) to "How much does it
break BC and are we okay with that?"

In the context of the HTTP_RAW_POST_DATA discussion this means thinking
about questions like a) how much code will be negatively affected, b) how
hard will it be for the code to be fixed and c) do the benefits in
performance, memory usage and/or functionality (significantly?) outweigh
the inconvenience of code-adjustments?



As some people have a hard time understanding that small BC breaks are
introduced routinely and intentionally, some examples of changes that are
considered "generally okay" for bugfix and minor releases:

Bugfix x.y.z -> x.y.(z+1):

 * Addition of new functions, if the function name is unlikely to already
be in (unconditional) use. E.g. the addition of getallheaders() for the
built-in webserver in PHP 5.5.7.
 * Changes in the behavior of functions where a) the old behavior was
considered buggy and b) not much code was relying on the old behavior (most
bug fixes minus crashes fall into this category)

Minor x.y.0 -> x.(y+1).0

 * Addition of new keywords, if the keyword is not commonly used in code
already. (E.g. "yield", but not "user").
 * Deprecation of functions or language features. In practice deprecation
of heavily-used components like ext/mysql is *one hell* of a BC break, but
we're okay with it for minor versions. (This also includes addition of
other non-fatal errors)
 * Removal of long-deprecated or little used functionality. E.g. the logo
guid functions were removed in 5.5.
 * Changes in the behavior of the language where a) the old behavior was
considered buggy and b) not much code was relying on the old behavior.

Thanks,
Nikita

PS: I think that it would be nice to adjust the releaseprocess RFC to
clarify this point, to make things clearer for both contributors and
end-users. The current promise sounds a lot like "You can just update from
5.4 to 5.5 and won't need to make any code changes", but for any
non-trivial (legacy) codebase that's pretty far from the truth.

  [1]: https://wiki.php.net/rfc/releaseprocess
  [2]: http://xkcd.com/1172/

--089e0149ca10e621cf04eb8c7ed2--