Backwards Compatibility Shouldn’t Be That Hard
Let me just get this off my chest - I hate upgrades. Upgrades of most things are never as easy as the UPGRADE file says it should be. Linux, your pc, your house, invariably, something usually goes wrong.
Over the past few weeks, we’ve been trying to manage our way through the mess that is upgrading Drupal 5 to Drupal 6. There appear to be some nice features in this latest version like major speed improvements and the ability to translate any piece of content. Unfortunately, the Drupal foundation did several two bad things.
1) Deprecate functions by deleting them
Now, I’m all for deprecation, but you I firmly believe that you need to mark something as deprecated before you go and delete it. Saying that something is deprecated from one major version to another and deleting it in that same version makes a huge mess of things - especially open source projects that get their value from the wealth of community modules out there. Deleting the functions in Drupal 7 would have made more sense and probably made this upgrade go a bit smoother for people.
2) Release without two of the primary community modules ported
Most Drupal installations have two very important modules installed: CCK and Views. Currently, both of these modules are still in “beta”, and weren’t even in beta until the last few weeks. Drupal 6 has been out for months. In addition, there are probably 50 or more modules that depend on those modules. I would figure that most average drupal installations use between 30 and 100 additional modules. They’re easy to install and things start to go downhill 
3) Switch PHP Error reporting to a more strict mode
Honestly, I have mixed feelings about this. In Drupal 5, you could be a little fast and loose with things, letting PHP say that a missing variable was as good as saying a condition was false. In Drupal 6, they’ve made PHP’s error reporting be E_STRICT and I’m not always convinced that it reports things that should be warnings. Variables that are clearly there sometimes get reported as not available. From a Java background, this type of mode is familiar, but I don’t have the compiler to catch it (or IntelliJ to tell me that a variable might evaluate to null!). This particular change has been the one that caused the most pain. I guess next time I won’t be so sloppy
To be fair, I didn’t feel like it was all that hard to convert our modules (the theme was a bit harder to do). Our in house modules didn’t really depend on any community modules though. If your module depended on another module that depended on another module, you’re left in “wait and see” mode for a long, long time. What I’m concerned with is this: the Drupal committers appear to be on a path of a new major release each year. Are we going to see the same pain for Drupal 7? The early signs are that theres some serious new stuff coming down the pipe and if the past is any indication of the future then we could be in for a bumpy ride.
Filed under: Opinion | No Comments »