email article
	printer friendly
	more resources

Scaling Over Time: The Version Problem
See how to solve the problems surrounding management of a system's changes over time.
by Alex Krapf

January 19, 2006

A lot of scientific papers and articles have been written about scalability. The focus has almost invariably been on the problem of scaling over resources or usage patterns, such as scaling over a number of processors or scaling over a number of requests. The problem of scaling over time, however, has largely been ignored.

By "scaling over time," I'm referring to managing a system's changes over time. Today, you usually scale over time by using a version control tool. You typically have the ability to revisit a snapshot of your entire codebase at a certain point in time. You can also look at a former version of any element in your codebase, normally at file granularity. Sophisticated version control systems might also allow you to deal with the elements of your system in terms of a change set, essentially combining changes to related elements into one conceptual change.

Version control systems are obviously an important part of your development infrastructure. Their features and capabilities have a large influence on your development process. Regardless of their feature set, they are all based on one unspoken premise: Versioning is a concept external to your code.

In today's development process, the idea of a version is introduced after you have written your code. The different versions of code that you use are essentially labeled snapshots in time. A later version of an element will not contain any information about the earlier version; all such change-related information exists only outside your code, as metadata in the version control system.

If you were to look at the evolution of a type T in a system, you might see something like this:

In version 1.0 of this product, I used the original version of type T. It remained unchanged until version 2.0, when I modified the type, and it became type T'. Then I immediately realized that I had to make another change, and it morphed into type T" with version 2.1. I didn't modify the type further throughout the remaining versions of the product.

Please note that in this example I have not made assumptions about the backward compatibility of any of the changes. The change from type T to T' might have been backward-compatible, while the change from type T' to T" might have been incompatible. The important thing to understand is this: Type T might undergo an evolution that is largely independent of the release numbers or version control labels. What's more, type T might not correspond with an element in the version control system. It might be a small part of a file, or on the other hand, it might span several files.

Traditionally, I have used the release number of a product to version an entire set of types, whether or not they had changed. I bundled a snapshot of the system into a deployment unit that might have a version number associated with it, such as a jar file or a shared library. I typically regard releases as black boxes and do not anticipate that implementation types of different product versions will coexist. Consequently, I often use the same, unchanged type name to represent different versions of a type. The assumption is they will never have to coexist in one context because they represent unrelated points in time.

Developers are increasingly running afoul of this core assumption. Yes, you might have discrete releases of software that never have to coexist, but type T might be a public API used by clients that have their own release schedule. It might be a persistent type, instances of which might be written out by version 1.0 of a product and (attempted to be) read by version 3.1. How does your version control system help you with these problems? The answer is: It does not help at all.