Last week I posted about versioning challenges related to naming conventions and determining which version is actually the final one. This week's post continues this idea and discusses different styles of versioning (linear or major/minor), tracking methods, and when draft versions should be kept or destroyed.
Versioning Styles: Linear vs. Major/Minor
Many of the new ECMs (EIMs or repositories) now come equipped with functionality related specifically to versioning. Some systems allow what’s called linear versioning. Each time a document is modified it gets saved back into the system as a new integer in the sequence (1, 2, 3, etc.). However, there are certain systems configurations and decisions that need to be considered with this type of a set up. For example, how many versions of a document should one keep? How many versions does one need to keep?
One of the challenges with linear versioning is that it doesn’t distinguish between a major overhaul of a document or minor format tweaks and corrected typos. This means it can be difficult to identify which previous versions, if any, will need to be retained. Also, depending on which platform is being used and how it’s configured, versions will be “created” in different ways.
At one job I was using Content Server set up for linear versioning. When working on documents it’s a habit of mine to hit save periodically in case the computer freezes, or I get called away, etc. With Content Server, each time I hit save it registered as a new version but would only show the version number when I “returned” the document back to the repository. For example, if I opened up a document that was version 6 and hit save 5 times while I was working on it, when I eventually checked it back in it appeared as version 11 and versions 7-10 did not appear and were not available for viewing. I personally found it confusing that “versions” were recorded, but with no way to actually go back to any of them.
I’ve worked in other types of repositories, such as SharePoint, that allow for major and minor versioning. Usually a major version receives a whole integer (e.g. 1, 2, 3) and the minor version is expressed with a number following a decimal point (e.g. 1.1, 1.2, etc.). Major/minor versioning can be useful for distinguishing between major reworks on a document or minor edits and small changes. The complexity with this option happens with defining what constitutes a major or minor version and how to make sure this is understood and adhered to consistently when working with a group of people.
Other considerations concerning major/minor versioning are related to access permissions. Some systems allow for viewing/editing permissions to be granted or restricted based on the whether or not the document is a major or minor version. This function doesn’t have to be employed, but it can be useful in certain scenarios where it may be beneficial to have working versions (i.e. minor) before they are ready for broader dissemination or publicizing (i.e. major).
Other Tracking Methods
Since one of the main ideas behind versioning is to track the document’s development, it seems logical to incorporate a document’s status (i.e. draft, pre-final, final, approved, etc.) as part of the process. I’ve seen this handled in a number of different ways in both shared network drive environments and those using ECMs or repositories with more sophisticated versioning functions. Here are some of the methods I’ve seen:
- Using folders to track the status of the versions – basically the document is moved (or copied) into a folder based on where it is in the process
- Appending the status into the name of the document (e.g. DRAFT – document name – date)
- Inserting a tracking sheet directly into the document for version control
Probably the most important thing is to have a tracking method and firm rules about naming conventions and versioning styles. This all leads to one of the biggest decisions, how to determine which versions to save and which ones to destroy.
To Keep or Not to Keep?
From a records perspective, the answer to this question varies considerably based on the organization and the nature of the records. I personally tend to destroy my working versions once the final (the true final) is ready. If it was a document that went through radical revisions, I might hang onto the working versions for a limited period of time, such as 6 months or a year, but generally tend to get rid of them, unless I'm required to keep them as per a records retention schedule.
I’ve noticed a lot of variety in how people treat draft versions leading up to the “final”. Some users will create folders named “Old” or “Archive” and move all the previous versions into them. Other users, who may be working in ECMs or repositories with more sophisticated versioning functionality, may opt to keep all the previous versions, to pick and choose some versions to keep (e.g. a certain number of versions or only the major ones), or to have previous versions automatically purged once the final is declared. And some people save changes over the previous version so there is only one version at any given time.
Similar to all the other aspects of versioning, it’s worth opening the dialogue with key stakeholders to establish business rules around which versions to keep. I’ve seen records retention schedules that will either have drafts and finalized documents as two separate records series, or will include drafts into the scope note for one particular record series.
Versioning, in my opinion, is just one of those things that seems really easy and obvious at a first glance, but is actually quite complicated and nuanced. It’s a good idea to make sure versioning is part of the discussion when incorporating new technological solutions or when working with business units to improve current RIM practices.