OStatic

Engineers like to solve new problems. They like to create new things. They like to think about the future. Dealing with old problems is not as attractive, exciting, or interesting as creating new solutions.

So it should come as no surprise that hardware and software engineers have wrestled for years with the issue of "backward compatibility" -- the idea that new hardware and software should be just like the old hardware and software, only faster, more reliable, and better.

Everyone who has ever dealt with a computer has had to think about this, to at least some degree: When you upgrade your operating system, will it still work with your printer? When you upgrade your word processor, will it still read your old documents? (And will people who have not yet upgraded be able to read documents written by your new version?) When you upgrade to the latest version of your favorite programming language, have any old constructs gone away, or changed their meaning?

Microsoft is well known for taking what could be called the "extreme-compatibility" view, working to ensure that as many old programs will continue to work with new versions of Windows and Office. Much of the uproar over Windows Vista was not just over the program's price and feature set, but the many incompatibilities that users discovered after installing it.

The open-source world, as you might expect, takes a much different view of backward compatibility. On the one hand, because changes are publicly posted and debated, there is rarely an element of surprise; developers and users know what changes are coming, and are able to prepare.

But even more importantly, because there is no financial incentive for open-source programmers to force you to upgrade, you can often stay with an older version of a program for quite some time, upgrading only when you feel ready. Moreover, upgrades often happen over time, particularly with programming languages and frameworks, first indicating that you are using a feature which will go away in the next version. And even when things have changed dramatically and incompatibly, there is generally a way to fix this.

For example, Ruby on Rails 2.0 removed and changed a number of functions. Rather than simply going from "working" to "not working," pre-2.0 versions of Rails "deprecated" those functions, inserting warning messages in the logfile that said something like, "You can use this function now, but you should change it before upgrading to Rails 2.0, because then things won't work!" By reviewing warnings in the logfile, programmers were able to locate and change the offending code before it was too late.

Other systems have other means of deprecating functionality. For example, Python has a clever system known as __future__. Before an incompatible change is included in the Python language, it is first available within the __future__ module, allowing anyone to use "future" functionality by stating "import __future__". Over time, features are moved from __future__ into the mainstream version of Python, first producing deprecation warnings and then becoming incompatible.

Both Perl and Python are currently undergoing massive rewrites, such that users of Perl 6 and Python 3000 are likely to encounter many incompatibilities. This is only natural; after so many years of relatively few incompatible changes, the languages need to undergo some revolutionary change, and not just evolutionary change.

Perl 6 will look and act quite different from Perl 5, and there are many (including me) who wonder if this makes Perl 6 effectively DOA before it has even been released. The authors of Perl 6 counter that they will have a Perl 5-to-6 translator, which will make it easy for anyone to upgrade the language. A similar tool (called "2to3") is being prepared for Python 3000, in order to ensure that the maximum number of programs can be upgraded.

Databases are a particularly difficult issue to deal with, since they typically store their information in tightly packed, binary formats. PostgreSQL is notorious for forcing people to "dump and restore" databases between upgrades, a task that is less onerous than you might expect, but which is still a bit annoying. This only occurs with point releases (e.g., 8.2 to 8.3), however, and is increasingly automated in Linux packaging systems such as Debian's "apt" system. However, there isn't any automatic indicator, or deprecation warning, that database programmers or users can take stock of in advance, other than the release notes for a given version of PostgreSQL.

Upgrades are never pleasant, and there are always issues associated with them. You are never required to upgrade open-source programs, although you will generally find that doing so gives you additional features and performance, as well as fewer bugs. That said, the open-source community is increasingly sensitive to these issues. By paying attention to the deprecation and compatibility warnings used by your favorite open-source package, you can ensure easy and carefree upgrades.

How do you check for compatibility? And how do you think that it could be improved?

• python
• open source
• ruby on rails
• postgresql
• vista
• upgrade
• perl