The odd bit

Once is an accident, twice is a coincidence, three times is an enemy action.

The odd bit - Once is an accident, twice is a coincidence, three times is an enemy action.

The importance of backward compatibility

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!

  • Kristof says:

    Hi Hans

    That’s probably why they call the current Zend releases “preview releases”.

    http://framework.zend.com/wiki/pages/viewpage.action?pageId=10523

    I guess they have a good reason to change stuff like that. Any references to an issue report or something similar?

    19 December 2006 at 17:54
  • Hans Melis says:

    Hi Kristof

    They do call it preview releases, but also “stable preview releases”. And to quote something from the page you referred to: “your existing code may need to be tweaked in a few minor ways to accommodate those changes” is a pretty big understatement 😉

    What bothers me most is that a similar project (read: eZ components) never had this issue. Some “minor tweaking” at most, but never major breakage.

    Another point is that they do have an incubator. What’s the point of an incubator if you’re also doing complete rewrites of “stable” packages? There’s also not much point in having a preview release if the next one is going to be completely different.

    I’ve found the issue [1] about loadInterface(). And the other thing I mentioned about the abstract method [2] is a bug I think. I know it doesn’t work out of the box 😀

    But it’s actually a problem of the past as I’m in the process of removing ZF code.

    [1]: http://framework.zend.com/issues/browse/ZF-329
    [2]: http://framework.zend.com/issues/browse/ZF-124

    19 December 2006 at 18:18
  • Paul Borgermans says:

    Hi Hans

    Indeed you pointed to a painful aspects in the Zend framework development: the interface changes and inconsistent implementations afterwards do not match with the spirit (or let it be a desire) of a professional platform for PHP based solutions. But maybe the Zend framwork is too premature to judge.

    I had a similar feeling with the Lucene implementation of their search component: it’s like pretending a raw egg can be properly cooked in a nicely decorated freezer. It doesn’t. (and for the curious: the problems are basically the lack of high performance persistence of datastructures in PHP like they exist in Java or unspokendotnet; memcache interfaces only stop some nose bleeding here)

    Paul

    20 December 2006 at 01:18
  • Lars Strojny says:

    Most of the time it is more easy to spend the five hours to convert to the new API as to provide backwards compatibility in a library. But one have to be careful if he breaks API. Your example seems not to be very well thought-out.

    21 December 2006 at 01:33
  • Patrick VEach says:

    Similar problem. The Controller stuff is essential to the program, when it goes, it blows! Not sure what to do about it. The front controller is the main reason I use ZF. The documentation seems to be getting worse not better. All the examples are from .0.2.0 pre release or earlier. No chat room where you can talk to someone who has a functioning system. etc. etc. :[

    2 January 2007 at 02:09

Your email address will not be published. Required fields are marked *

*