Backward compatibility is often abbreviated to just BC, but those two letters stand for an extremely important issue when it comes to software development. The sad thing is that you only realize its importance when backward compatibility is broken. Let’s take a look at what happened.
I’m working on a personal PHP5 project and I’m using two libraries: eZ components and Zend Framework. I started with 2006.2beta1 of the components and version 0.1.6 of the framework. Both software packages had an upgrade to 2006.2beta2 and 0.2.0 respectively, and almost without problems too. The Zend Framework’s controller package had a rewrite so the code dealing with routers needed some changes. No problem, they even announced that change so I knew I had to change the code.
Fast forward to today… Stable release of the eZ components 2006.2 and version 0.6.0 of the Zend Framework which was released a couple of days ago. I installed the new version of the eZ components: no problems noted. I installed the new version of the Zend Framework: fatal error season started.
Intermezzo: the framework has a so-called stable library and an incubator (a folder where new packages can mature before they go into stable). I know incubator stuff can change drastically so I’m not going to moan about that (haven’t used an incubator package anyway). What I expect of a stable library is that applications don’t just break when a new version comes out.
Well, it broke badly! The framework has a base class named Zend. The class had a nice static function to load classes (mapping the framework’s naming convention to file structure) and another one for interfaces. One bright mind decided to deprecate the function for interfaces and made it throw an exception when called. The comment only mentions “use require_once()”. What?! First they give me a method that I can use in the magic __autoload() function so that I can just type the name of an interface and have the file included automatically. Now they deprecate that method and want me to go through the code and use a require_once to manually include the interface. That sure is backward, but far from backward compatibility.
They also changed the signature of an abstract method from 1 parameter to no parameters even though they still call that function with a parameter (in the very same class). And that’s just the tip of the iceberg. If you have to rewrite a stable package, you have a serious issue somewhere in the design process (assuming there is such a process of course). All this breakage raises the question if I should just throw the framework out of the code, but that idea needs further analysis.
But let’s end this post with a positive thought. I think a double thumbs up and a word of gratitude towards the eZ components team is not misplaced here. Many thanks for maintaining backward compatibility!