Why Upgradability Is Hard: An Overview

In an ideal world, the system only makes forward progress. Each version (or revision, year model, or other equivalent terms and concepts) is carefully planned, and all consumers (or users, receivers, or other equivalent terms and concepts) upgrade the system accordingly:

Unfortunately in reality things are complicated. If the system is a distributed one (i.e. each consumer has their own copy), this is what might happen. This is especially so when a provider (manufacturer, developer, seller, or any other similar concept or term) runs a policy of planned obsolescene—somethings out of practical reasons like inventory control, and users who are still using V₁ will then have no choice but to upgrade directly to V₃. Any system that does not have such "jump-start" plan at Day 1 is awaiting disasters.

Although this is often an argument against desktop application (contrary to "web apps"), remember the complexity is either shouldered by the end user or the provider. Plus, if end user has, for example, downloaded data, then data format also has the same problem. Not even web app can escape this systematic challenge.

Things are even more complicated then the end user is given the freedom to downgrade. The upgrade path now needs to take both downgrading and jump-start upgrading into consideration.

A "patch", or "service pack" in some software vendor speak, is something that amends, fixes or enhances certain parts of a system (usually software, but this does not only apply to it). Although we may imagine enough patches accumulate to, culminate in, or simply "morph into" another full version, it is often not the case.

Suppose we only allow forward upgrade here, and jump-start upgrade is only allowed on versions but not patches, the number of possible upgrade path in the example here is 12. The number only grows exponentially as the number of versions and patches goes up.