First up, thanks to David O'Shea for his comment about Cisco's version labelling. Makes the Oracle example from part 1 look straightforward in comparison.
This time, I wanted to talk a bit about the semantics of versioning - what it means, what people think it means, or want it to mean. We look for meanings in things. It's a natural part of the way humans interact with the world around them. We look for patterns in things. So it is natural that when versions of things are labelled, people want to be able to attach a meaning to the way a new version label differs from the previous label.
As an example, I have a Nokia 6680 mobile phone (cell phone). Nokia use 4 digit numbers to identify their phones, and these numbers are not far removed from version numbers (think of a new phone model as being a new version of some old phone model). I know that Nokia 9xxx phones are brick-shaped, and that 3xxx phones don't have enough features for me. So I knew I wanted a 6xxx phone. I was able to determine that much meaning from the numbers which identify the phones. From there, however, I fail to find any consistency at all. Higher numbers don't necessary correspond to more sophisticated phones, and I found it difficult to work out which of their phones were ones that suited my needs, and that I should be comparing. If the numbers categorised the phones in a more consistent way, in a more meaningful way, it would have made things easier for me.
In general, people look for the same kind of consistency and meaning in version labelling. So what kinds of semantics or meanings are we talking about? The one thing that different version labels guarantee you is that the two versions might be different. That's extremely weak, though, since they might be the same (it's quite common within version control or configuration management systems for a single version of a file to carry multiple labels). In general, though, when the version label is different, something is different. This is the philosophy that is often used in labelling software builds, where the build label is an integer that just increases by 1 for each build. The new build version tells you that something is different (or at least that something was the product of a different build), but it doesn't tell you anything about the nature of the difference.
Much of the decision making that we do in our lives is around categorising which things are significant enough to have to factor them into our planning, and which things we can ignore, at least for now. So people rarely are satisfied by knowing that something is different, they want to know how different. Is it a big change or a small change? It's a simple enough question, but complex to answer, since something that seems like a big change to one person may seem like a small change to someone else with different criteria.
Still, the impact of this need is obvious enough, since the most common way to version software is to have a major version number and a minor version number, e.g. "1.0". A change to a major version number is perceived, at least visually, as a "big" change. A change to a minor version is perceived as a "small" (or "smaller") change.
Actually, this distinction between major and minor has been largely hijacked by the "backwards compatible" school of versioning. That is to say, if the new version is compatible with the previous version, it is a minor version change. If it isn't compatible, it must be a major version change. People like this rule because it is simple and objective. At least, it sounds simple. Actually, there may be multiple ways of defining "compatible" for a particular versioned item, and some of those different ways won't always give the same result. As an example, a "backwards compatible" XML schema is usually defined to be one for which older documents (created for earlier versions of the schema) are still valid. However, if you "compile" your schemas into a Java/C#/etc. API, "backwards compatible" can be judged by whether the interfaces in the new version of the API are strict extensions of the interfaces in the previous version. These are both valid ways to judge "backwards compatible", but they don't give the same results. That means you may have to make a judgement call on whether one of these definitions takes priority over the others, or whether you decide to take the approach that "backwards compatible" means backwards compatible for all of the different definitions that apply.
In spite of all that intellectual rigour, this way of defining major and minor versions often proves unsatisfying to users. A change that is backwards compatible can still be a big change, one that feels like a major change to its users. A change that is formally backwards incompatible (e.g. deleting just one field that nobody uses any more) may be a minor one for the users, but the strict "backwards compatible" rule would require you to use a new major version number. This can be counter-intuitive for users, just as Nokia's number convention for its phones is somewhat counter-intuitive for me, and that is a problem.
So, it is important to remember, when coming up with a versioning strategy, that some "objective" rules for version labelling can produce counter-intuitive labels. You can argue that users shouldn't try to read semantics into labels, but they do, that's just what people do, and I for one don't see much point in trying to pretend that people don't behave the way they do.
In the next part, I'll discuss some ideas for human-friendly version labelling.
RSS 1.0
Follow me on Twitter
Recent Comments