Re: Making "backwards compatibility" discussions more constructive

Hi, While I agree that in general maintaining backward compatibility is a good thing, should there be a limit to how far that goes? Refusing anything that causes a BC break except for major releases makes sense, until you remember that PHP's major releases have a tendency to last 8-10 years if not longer. That's a pretty long time to wait for potential enhancements / sane changes to the language isn't it? There's the obvious point that security issues can be exempt from this particular rule when necessary, and there have been various other breaking changes (bug fixes or not) in minor point releases to date, but should / could the requirement of no BC breaks for minor revisions be relaxed? Where would the line be drawn? Personally, I have no idea. Cheers. On Wed, Nov 20, 2013 at 8: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. > > > * Changes in the behavior of functions where a) the old behavior was > > considered buggy and b) not much code was relying on the old behavior > (most > > bug fixes minus crashes fall into this category) > > I disagree. Misbehavior must be fixed and it indeed can break BC if > some code relies on buggy behavior. But I do not see what wrong in > fixing bugs. It sounds pretty obvious to me, but if you have arguments > why we should re consider that (aka stop fixing bugs), please post > them :) > > > > Minor x.y.0 -> x.(y+1).0 > > > > * Addition of new keywords, if the keyword is not commonly used in code > > already. (E.g. "yield", but not "user"). > > * Deprecation of functions or language features. In practice deprecation > > of heavily-used components like ext/mysql is *one hell* of a BC break, > but > > we're okay with it for minor versions. (This also includes addition of > > other non-fatal errors) > > Deprecation is a flag matters, more noises in the log is not > considered as a BC break. > > > * Removal of long-deprecated or little used functionality. E.g. the logo > > guid functions were removed in 5.5. > > Right, that one is actually a BC break. I was not fund of it but > seriously I cannot imagine production code relying on that. That's why > it fits in the acceptable category. > > > * Changes in the behavior of the language where a) the old behavior was > > considered buggy and b) not much code was relying on the old behavior. > > Same argument than the one for general bug fixes. > > > > > > Thanks, > > Nikita > > > > PS: I think that it would be nice to adjust the releaseprocess RFC to > > clarify this point, to make things clearer for both contributors and > > end-users. The current promise sounds a lot like "You can just update > from > > 5.4 to 5.5 and won't need to make any code changes", but for any > > non-trivial (legacy) codebase that's pretty far from the truth. > > And that's exactly what we try to avoid. As it cannot be avoided 100%, > we should be closed to 100% and not "far away from any code > modification while upgrading". > > We can make the RFC even more restrictive but then I'm not sure it > will be that productive, that will defeat your goals or ideas as well. > > Cheers, > -- > Pierre > > @pierrejoye | http://www.libgd.org > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >