Well, fixing a segfault, adding a new function or method as it oft happened in PHP 5.3 is only breaking forwards compatibility not backwards -- if you have code that ran on PHP 5.3.4 it'll run on 5.3.5. The reverse is not true which causes some headaches to Drupal developers but it's not relevant to this discussion.
So, what about adding a version string to the opening <?php tag so that you can fix bugs while not breaking BC :P ? On Sun, Feb 3, 2013 at 1:55 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > On 02/03/2013 01:48 PM, Karoly Negyesi wrote: >>> We do not consider a change [...] a BC break >> >> Let me help: backwards compatibility means a host can upgrade a >> package without inducing a lot of support tickets. > > Well, that is obviously not realistic. Every change we make has some > level of BC impact. We have to draw a line somewhere. Heck, even fixing > a segfault is technically a BC change because the behaviour from one > version to the next is different. A 100% strict "no BC" rule would mean > we couldn't actually ever fix any bugs. There has to be a line. Our line > is that in minor version upgrades we won't change documented functional > behaviour unless there are extremely serious (usually security-related) > reasons for doing so. > > -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
