Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62929
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nHcajD1zkUbnPo8QtK3CEO4cx7Vwk0RGOV6vGBhdK=vJQ@mail.gmail.com>
References: <CAMUwpuRdHMmbYSj1nqbKSdV=23SA20J0udaU-CYmHBRbZ40NeQ@mail.gmail.com>
	<CAEZPtU7Nue-XVHeeSpt2ff82_F5Y7-vcB38UHoDqaLfY+1BnfQ@mail.gmail.com>
	<CAAyV7nHcajD1zkUbnPo8QtK3CEO4cx7Vwk0RGOV6vGBhdK=vJQ@mail.gmail.com>
Date: Mon, 10 Sep 2012 20:38:58 +0200
Message-ID: <CAEZPtU4DLtwoBYGihDquzbj23rhL0BNJ5v+WvY=HL6HVvX99Hg@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: jpauli <jpauli@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] What is our definition of a "Backward Compatibility Break"
From: pierre.php@gmail.com (Pierre Joye)

hi,

On Mon, Sep 10, 2012 at 8:23 PM, Anthony Ferrara <ircmaxell@gmail.com> wrote:
> Pierre,
>
> On Mon, Sep 10, 2012 at 1:54 PM, Pierre Joye <pierre.php@gmail.com> wrote:
>>
>> hi,
>>
>> On Mon, Sep 10, 2012 at 6:28 PM, jpauli <jpauli@php.net> wrote:
>> > Based on our recent discussion on #pecl , I'd like we clarify what we
>> > think is a "BCB" (Backward Compatibility Break) as well as what "only
>> > minor BC breaks" could mean.
>>
>> Change in phpinfo related stuff are minor. Adding a notice or warning
>> is minor or irrelevant. Changing return values (like suddenly
>> returning array instead of integer, f.e.), behaviors or similar things
>> are not allowed in x.y+1.
>
>
> I'm not so sure about that. Adding a warning or notice may actually cause a
> lot of headaches. See what happened with call-time-pass-by-reference in
> 5.3... All of a sudden a lot of code that worked fine is flooding logs with
> new warnings...

it does not break code, also that happens only and only from 5.x to
5.x+1 and should not happen from 5.x.y to 5.x.y+1 for example (or on
very rare cases).


> I guess my point is that the line between a BCB and a minor BCB is a lot
> finer and a lot more subjective that it seems on the surface. Is adding a
> new language feature with a new keyword a BCB (since existing functionality
> using that keyword is now a parse error),

We add new features, that's no BC break as the feature did not exist
before. Keyword is a problem, but we have to live with for now.

> My take on it is this:
>
> If you can solve the "break" using nothing but static analysis and a static
> conversion "script", then it's a minor break. So new keywords would be fine
> (you could find/replace function yield() with function yield2() really
> easily). But changing the semantics of code (returning an array instead of
> an int, changing how references are passed, etc) would require developer
> interaction to fix, and as such would not be minor.
>
> And one point on what classifies as a BC break: Everything. Any change will
> break BC in some way. Even adding a function is a BC break since existing
> code may use the same function names.

Why we added namespace, no issue (well for 5.3+ :).

> Fixing a segfault is a BC break as
> well, as it's changing the way it works.

That's really a totally wrong example.


Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org