In an article I wrote for InsideRIA I asked "is backward compatibility important for a RIA platform". Curl doesn't build its runtimes to be "guaranteed" to be backward compatable - we use a different approach which we believe is better for our product and our customers. I spoke with David Kranz and Bert Halstead and got more details from them. The following is derived from emails from both those folks and should provide you with more details about Curl's backward compatibility story.
According to Bert and David:
There are several issues that are wrapped up in the notion of "backward compatibility" with regard to a platform, as opposed to an application. One is what happens when a user upgrades the platform. What happens to the existing applications running on that platform? We hope the answer is that they keep running. This can be accomplished in one of two ways.
One common way is that the new version of the platform replaces the old version and that the new version cannot change the existing behavior. This is the way browser-based platforms generally work, as well as operating system upgrades. This makes it difficult for a platform to evolve and also places a huge testing burden on the platform. And since it is so hard to achieve true, 100% compatibility, it also forces application developers with mission-critical applications to constantly make sure their applications work on new versions of the platform their application uses because a new version may be installed "underneath" the application, possibly causing it to break. Moreover, none of the other platforms are fully backward compatible -- Adobe has made various changes in ActionScript, Silverlight 1.0 and 2.0 are very different, if Java ever removes any of the deprecated APIs, like they say they will, then it won't be backward compatible either," etc. So promising backward compatablity and executing on the promise are two different things.
The other way to make sure that applications developed for older versions of a platform keep running is "side-by-side" versioning. This is the approach taken by platforms such as Visual Basic, and Curl. In this case an application is built to run on a particular version. When the user installs a new version, they do not replace the older one. Until they are upgraded, old applications use the old version of the platform and so are sure to keep working. New and older applications both continue to work. One advantage of this approach is that developers do not have to worry about how their application runs on new versions of the platform until they want to upgrade.
Another advantage is that the platform is not required to be 100% compatible.
Of course, any incompatible change is a potential burden to developers and should be avoided unless developers are provided with important functionality in exchange for possibly having to make some code changes when they upgrade. Curl's policy, which is to evolve APIs, even from one major version to the next, in a backward-compatible way whenever there is any reasonable way to do it.
For an enterprise, our approach to "side-by-side" versioning is a big advantage or the enterprise. It allows an unterprise be able to run applications without upgrading for as long as they want, and not have to suffer a forced upgrade of all of their applications just because they have some new application they want to use. It is also a big advantage to be using a platform that can evolve without the burden of having to make sure that all existing applications running on the platform behave in exactly the same way with the new versions.
