Versioning Protocol (And, How Rawls Rolls)

The other day Brett Rawls, the head of sales and marketing, got handed the keys to a bumble bee-colored Camaro at the rental counter.  While he gave a little protest, the 15-year old kid inside him was already on the road in 5th gear. Now, Brett is a pretty button down guy that is more accustomed to a minivan than a muscle car, but he couldn’t stop smiling.  In fact, that bright yellow car made Brett even happier and more outgoing than he normally is. In versioning parlance, the car made Brett 3.0.


    If you are already picking up what we are putting down and are wise to the ways of document versioning, then this article isn’t for you. However, we have seen some crazy attempts at version titling from bankers. Just the other day we saw the file “StrategicPlan Final 031413 v34_5 Final Final GK.doc.” We are not sure what that means, but we are pretty confident that it is not the final version.   We also have no idea what lawyers are doing as somewhere in law school they teach you to version with a minimum of 15 digits. Regardless of how you do it, we would like to suggest the following:


   Document version titles usually takes place along two lines. One is the simple date protocol where you put the name of the document and then the date. This is favored by academics.  If you are producing multiple versions within that date, each save then gets a time (usually using the 24 hour clock). While most efficient, the problem is that just using the date/time doesn’t tell you about the publication status of the document. This protocol also assumes that the document is revised in a linear fashion and that two version of the documents are not being revised at the same time.


  The other way to go is to use build numbers. This is favored by software programmers, engineers and government types (this is the methodology of the rocket scientists at NASA). Here, every time you publish the document to a committee or public, you add a 1.0 to the version. Whenever you work on a draft that goes to the right of the decimal, as in 1.3.  Thus, a bank in its 10th year might publish “Strategic Plan v10.2. in order to let everyone know it is the 2nd draft of its 10th published plan.” Date and author information is contained in the file (also called meta data) so there is no need to include this in the file name. 


   Things get a little more complicated if you are working in a collaborative environment so that changes are taking place simultaneously, but in this case each person or each department is given a unique identifier (such as using initials). Thus, in this case, “StrategicPlan v10.2CN.1” would be that CN produced a version off version 10.2 while “BR” might have produce v10.2BR.1 at the same time.  When these two documents are submitted and combined, the software or document owner would make the next version 10.3.


  Having a standard versioning protocol is good practice and allows the bank to go back and have a documented trail of changes should you ever want to resurrect a cut paragraph. We also suggest a versioning page within the document, but we will cover that in a couple weeks. Until then, think about adding more rigor to document titles and keep an eye out for Brett 3.0 coming up behind you in your review mirror -  You can’t miss the color…or the smile.


Add new comment

Filtered HTML

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.