Re: Making "backwards compatibility" discussions more constructive
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
Thread (16 messages)