In March last year, Bernard wrote about the versioning scheme that we use here at Enguin Design. Now that we have used it for a couple years, we have found a few intricacies that we need to deal with and offer an extension to how we version documents.

Revsiting our needs for a good versioning scheme from the previous article, the version number give us a few key pieces of information:

1. How fresh is the document (or application)?
2. How many times has the document been updated?
3. How often is the document updated?

Our solution was a scheme similar to what Ubuntu uses:

[year].[month].[revision number]

Since using the scheme, our processes have evolved somewhat, and we’ve found a several limitations:

• We now perform many more revisions in-house before delivering them to the client.
• We iterate very often, and often post-launch iterations are for tiny adjustments.
• We now rely almost entirely on paper wireframes and prototypes, our first in-browser prototype is also the first round of design.
• We often go through dozens of paper revisions that have only minute changes.
• Paper revisions do not always occur serially.

Because of this, our current revision format has several problems:

• Clients (and future developers) can be confused by the revision number jumps.
• Revision numbers tick up very quickly, even for minor changes.
• It is a linear.

To deal with these problems, we have amended or versioning scheme.

Versioning 2011.07.2

[year].[month].[revision number].[minor revision number][thread letter]

In the updated scheme, the first three sets of numbers are the as before. The minor revision number and revision thread are almost entirely for developer's use. The minor revision number is published only in places where the developers may need to know changes have been made, for instance, edits on a content strategy document that we are revising internally before sending to clients. The thread letter is how we differentiate between possible choices for a single revision. Most often we use this for different wireframes to compare, but can be used at any point where there are a/b decisions.

The difference between major and minor revision numbers is not set in stone. In general, major changes such as rewriting or creating entire sections would be considered a major revision. In short, the decision to increment the major revision number is a judgement call based loosely on the complexity of the changes, and whether a major milestone or decision was made.

When there are minor revisions through multiple months or dates, the year and month will change but the revision will not. This way we can still keep track of the freshness of a particular revision, while keeping the revision number from growing out of control.