Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65586
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain negyesi.net from 209.85.216.49 cause and error)
MIME-Version: 1.0
In-Reply-To: <510EDCDD.3060508@lerdorf.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>
 <510EDCDD.3060508@lerdorf.com>
Date: Sun, 3 Feb 2013 14:03:04 -0800
Message-ID: <CAOfzkkwz2sgfWC1cH8cHQLH6naLW1C-kEMVEBSqHnJQ5rV9u8A@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
From: karoly@negyesi.net (Karoly Negyesi)

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 <rasmus@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