Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65600
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAOfzkkwU4=K86582q1kgh_w2Ecubxij-ExecBLF_aHEWMY=dew@mail.gmail.com>
References: <CAOfzkkz3DC+aVb4c73QHGRzZv=1z=nG4uexdJh2n8h3ATGBBOA@mail.gmail.com>
	<CAEZPtU6UdX4uyR7tLomi==DNbmJduHoxa=qmb+dd2bJQKcoxjw@mail.gmail.com>
	<CAOfzkkwQNKRrX+MQ3JutkVWmHsCLZetJMp7AubA52E+=MSCcXw@mail.gmail.com>
	<510EBF98.4060900@lerdorf.com>
	<CAOfzkkwU4=K86582q1kgh_w2Ecubxij-ExecBLF_aHEWMY=dew@mail.gmail.com>
Date: Sun, 3 Feb 2013 16:46:14 -0800
Message-ID: <CAKOpQSyuKoSY8JGNhYUxPNTECR30Kk8j8MY5r4tY0qS_xBju2A@mail.gmail.com>
To: Karoly Negyesi <karoly@negyesi.net>
Cc: Rasmus Lerdorf <rasmus@lerdorf.com>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d044282408fca7d04d4db6b67
Subject: Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
From: kris.craig@gmail.com (Kris Craig)

--f46d044282408fca7d04d4db6b67
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Feb 3, 2013 at 1:48 PM, Karoly Negyesi <karoly@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

--f46d044282408fca7d04d4db6b67--