Backward compatibility sounds nice, but it's not so easy to respect it in big
projects. And the whole interest is on big projects: it's maybe not
such a problem if your grand-ma's blog breaks its API on each release, but
there would be a revolution (or not?) if win32 API was changing on each
enslavement service pack microsoft releases.
Here is a real story case study of a BC break that happened on the PHP language itself.
It's always tempting to say «hey, this feature is so great, and has so little impact on the way it works, it may be cool to include it it the stable branch, don't you think?». Well, it can be cool, if it cannot have any effect on existing projects. But let's think again. How can it have no effect on the existing projects? And if it has no effect, why include it in this branch?
I don't think there is a definite answer to this, as it may have pros sometimes. But most of the time, it will have much more cons than pros. And if you doubt, forget it. Bigger is the project you work in, more it will have users depending on it, and if there is any way users could have used the old "buggy" feature, for sure they did.
I want to expose some real life case that happened recently, on the PHP distribution itself, showing its snowball effect through symfony to real life projects.
Let's have a look at this php bug report. It says «spl_autoload_functions() should return object instances, not class names, when appropriate.»
Two words are really interesting in this bug report. It is "should" and "when appropriate". There is many assumptions behind this. When is this "appropriate"? Why "should" it return instances? I would better rephrase it as «Feature request: spl_autoload_functions() must return object instances, as it is more appropriate than strings containing class names.». The overall formulation is not so much important as the facts that:
- It is a feature request, not a bug
- The function is currently working, but its behaviour can be changed to a more convenient one.
But it's ok, right? The target version was 5.3 while still no stable releases existed.
Yes it is.
Oh wait, let's read the comments now.
«Thanks for the fix. Do you think, by any chance, we can sneak this into PHP 5.2, or is that impossible?»
The definite answer to this question should be «It is actually impossible. Introducing a behavior change into 5.2 (years) stable release would break backward compatibility.»
And the patch made it to PHP 5.2.11.
Is there any consequences? Yes of course. In fact any symfony 1.3 projects were broken at this stage, because symfony used this behaviour with the reintroduced sfAutoloadAgain autoloader, which checked the return value for strings, and got instances, causing an infinite loop that made apache segmentation fault.
This is now fixed, by http://trac.symfony-project.org/cha..., but was the feature worth the hassle? How many projects can this kind of change break?
So for all you that work on big projects, think well, then think again, then don't do such a change. Usual formula says «With great power comes great responsibilities». I'd add «Great notoriety induce great responsibilities».
Yes millions of people uses PHP, and that's the main reason why stable branch should stay stable. Rock solid stable.
And it's the same reason why symfony branches stay stable, as much as possible. And any exception to this always have bad feedback.
(thanks to Pierre Joye for his reminder at http://news.php.net/php.internals/4...)
Note: Software stability does not only mean bug-free. It also means «not changing», and it's the main definition used there. Bugs are annoying, but they can be fixed to get the wanted behavior back, so it's not a problem. And the only wanted behavior of a stable piece of software is the behavior it always had.