Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70230
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.176 as permitted sender)
MIME-Version: 1.0
Sender: julienpauli@gmail.com
In-Reply-To: <CAEZPtU6vK-662TKmTe7uw-Kbv1XdetPunrOLZrKGxG8a5yLe-g@mail.gmail.com>
References: <CAF+90c_zyAr7kRnY9FArehhJ-QUxA-6B4TqNUx2Bzxwumbr1zA@mail.gmail.com>
 <CAEZPtU6vK-662TKmTe7uw-Kbv1XdetPunrOLZrKGxG8a5yLe-g@mail.gmail.com>
Date: Wed, 20 Nov 2013 12:00:18 +0100
Message-ID: <CAMUwpuT2KbErf=9qZYe-UeEC46nq4Hwy2dtus2fBK=OTJfm9Tw@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c3678c2bc89004eb99b23b
Subject: Re: [PHP-DEV] Making "backwards compatibility" discussions more constructive
From: jpauli@php.net (Julien Pauli)

--001a11c3678c2bc89004eb99b23b
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 20, 2013 at 9:23 AM, Pierre Joye <pierre.php@gmail.com> wrote:

> hi,
>
> On Tue, Nov 19, 2013 at 8:16 PM, Nikita Popov <nikita.ppv@gmail.com>
> wrote:
> > Hi internals!
> >
> > In a lot of the recent discussions (e.g. the HTTP_RAW_POST_DATA one) I've
> > seen the "we can't break backwards compatibility in PHP 5.x.y" argument
> > crop up again and again.
>
> It is not an argument, but a rule we try to respect.
>
> > This rather unfortunate formulation takes root in the releaseprocess RFC
> > [1] and drives all discussions of BC issues into a non-constructive
> > direction.
>
> As it can see as non constructive, the goal is to actually smooth and
> speed up updates, be direct end users or ISPs.
>
> > Fact is that nearly all changes (by being changes...) break backwards
> > compatibility to some degree [2] and we *do* most certainly allow them in
> > both minor and bugfix releases. Whether they are allowed (and for what
> > version) depends on the *severity* (rather than existence) of the
> breakage.
>
> We have discussed that already. However I cannot compare new features,
> keywords or functions as BC breaks. That's about namespaces or non
> guarantee that a given keyword won't be used by PHP in later releases.
>
> > I would really appreciate it if we could move BC-related discussions away
> > from "Does it break BC?" (Yes, it does, in some way) to "How much does it
> > break BC and are we okay with that?"
>
> Many small acceptable BC breaks do not allow one to update smoothly.
> Reducing newer releases adoption rate and increase the common opinion
> that all new releases cannot be used with current maintained PHP
> applications. I would rather avoid introducing new reasons to support
> this belief.
>
>
> > In the context of the HTTP_RAW_POST_DATA discussion this means thinking
> > about questions like a) how much code will be negatively affected, b) how
> > hard will it be for the code to be fixed and c) do the benefits in
> > performance, memory usage and/or functionality (significantly?) outweigh
> > the inconvenience of code-adjustments?
>
> The "amount of code" affected can hardly be an argument. Especially
> when we know that this code is actually used.
>
>
> > As some people have a hard time understanding that small BC breaks are
> > introduced routinely and intentionally, some examples of changes that are
> > considered "generally okay" for bugfix and minor releases:
> >
> > Bugfix x.y.z -> x.y.(z+1):
>
> Same as before, please explain why a bug fix can be considered as a BC
> break.
>
>
> >  * Addition of new functions, if the function name is unlikely to already
> > be in (unconditional) use. E.g. the addition of getallheaders() for the
> > built-in webserver in PHP 5.5.7.
>
> Was it added in 5.5.x and not present in 5.5.0? That should not have
> happened.
>
> That's gonna be reverted.
Revisions are bug fixes only, new features should come to master and
eventually specific branches when discussed and accepted as is.
We cannot afford a new feature / function in revision anymore like we did
in the past, that's too dangerous and clearly out of our release process.


Julien Pauli

--001a11c3678c2bc89004eb99b23b--