Making "backwards compatibility" discussions more constructive

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/