On Sun, Feb 3, 2013 at 1:48 PM, Karoly Negyesi <kar...@negyesi.net> 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. > > Best, > > Karoly Negyesi > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > As Rasmus already pointed out, 100% backwards compatibility is simply unrealistic. You would also be hard-pressed to find any scripting language out there that puts as much focus on maintaining BC as PHP does. Personally, I think we worry about it a little too much when it comes to major version changes. If you write your code to be scalable and have at least some sliver of forward compatibility, then minor changes like notices and warnings should not cause your codebase to blow up in your face. If they are causing that and fixing it would require "a lot of support tickets," as you put it, then I think the problem is with your code, not PHP. You should always anticipate possible changes in the language when writing your code if you plan on upgrading to the latest versions of the language. There is a simple solution for maintaining 100% BC: Don't upgrade PHP. Same goes for Perl, Python, Java, etc. If your code isn't forward compatible, just target it to the version it was written for and you're good to go. If you want people to be able to upgrade PHP, then you have to do your part by making your code scalable at least to a reasonable degree. I think we already do more than our part with how careful we are about behavioral changes in minor version increments. I also agree that different tags for different versions is just impractical and represents a maintenance nightmare. But if you really want to go forward with your suggestion, write an RFC to be voted on. I'd be happy to publish it to the wiki on your behalf, though I won't be voting for it. --Kris
