Conclusions
Software upgrades are an unavoidable fact of life for developers and users alike. They carry with them a significant element of risk: the new software version may simply not work!
This is just as true for an antivirus signature file update as it is for a Windows update; and the same applies for a full application upgrade.
Telecom systems have long used the model of partial upgrades. The same approach is also seen in high-performance, primary-secondary network processors.
In addition, database engines also use the same approach. Such applications as these have hard service level agreements that must be met.
Another aspect of these high-performance applications is their distributed nature. If you have two running instances of a database server with one backing the other up, then you can have two different versions.
In fact, the mechanism for upgrading such instances is often to initiate a failover from the primary to the secondary. The primary instance can then be upgraded, and then a failover is executed from the secondary back to the primary again.
At this point, the secondary can be upgraded. All without affecting service.
With the advent of dual-core desktop machines, it’s likely that desktop software upgrade mechanisms will become more complex. This should, in turn, help facilitate ongoing service.
The Commons Digester provides an elegant means of upgrading code. The code produced can be targeted at all users or just a select few.
This obviates the need for a single upgrade of all users, thereby reducing the risk and facilitating the end users’ needs.