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