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