As more and more people start using SharePoint we are finding that there needs to be governance around the version control of content. Common questions include how many versions should we keep, should we enable version history at all and what do major/minor versions mean? As always there is a balance between what your users need and the cost of providing them with these capabilities( physical storage, infrastructure and so forth)
So what do I recommend? Well as always it depends but here are some thing to consider. Regardless of what governance recommendations your implement remember this:
If you do not understand the content that you are working and the business process associated with it with you cannot create effective governance for it.
It’s the reason that there is no ‘Best Practices’ around this stuff because each organization is different. However here are some of the things you should consider once you do understand your organizational context:
Should version history be enabled at all
In my mind its either Yes or No. If you are going to be enabling version history for one library I would suggest that its enabled for all libraries.
You want to provide your users with some consistency and if some libraries have version history enabled and some don’t can make for a terrifying experience (Ask the person that uploaded a whole bunch of content on a library they though had version history enabled and it didn’t, thereby deleting all his content)
Now there are steps that you can take to avoid what I call “Version Bloat” where you simply store every single version of everything for no reason. But try to be consistent for your users, either have version history available in some way for your users in every library, or don’t turn it on at all.
Limiting Version History
Should you be limiting the amount of versions that are captured of a particular item? Well it depends but here are my rules:
For important content that need full traceability store all versions
If your content is very important and goes through many review cycles or is business critical then store all versions of the content. This is particularly important if you have legal or compliance issues that need to be addressed.
For ‘normal’ content store the latest 10 versions
For other content that is not business critical then store the last 10 versions of content. This will give users the version history they need but will limit ‘version bloat’ and keep your content databases to a sensible size.
For large file types limit versions appropriately
For large files make sure that you understand the impact on storage. You have a 50MB video file, someone makes a simple edit,you have another 50MB video file. This also occurs if a user is simply changing a metadata field. Even though this does shock people in SharePoint 2010 and previous this is how versioning is handled (Incidentally in SharePoint 2013 the Shredded Storage mechanism gets around this)
Of course if its critical digital content that needs full version history then that’s OK but make sure you understand this when architecting your solution.
For static content that relies on metadata limit version appropriately
We get a lot of our users to use metadata to categorize content instead of folder because of the many advantages of doing so.
But there can be issues with this. Imagine that you are storing large image files or PDF’s and the only thing that you are doing is changing the metadata associated with the content to categorize it but are not touching the underlying content itself. In SharePoint 2010 even if you change a single field and entire copy of the file is made.
Even though the content is static (you are not changing the actual image) by changing the metadata you are creating versions and hence taking up storage. In some cases this can really add up. Imagine changing metadata for a 5MB photo and ending up with 10 versions and hence 10X the storage capacity.
So if you are only change the metadata associated with content limit versions (or turn it off completely) because it is unlikely you will need a history of who changed what metadata.
Major and Minor Versioning
Major and minor versions also a set of questions that need answering. The most common question that we get when speaking to end users is:
When should we use Major versions versus using Major/Minor versions?
User Major versions only for items that DO NOT have a pre-defined lifecycle associated with them
If you have a simple library containing content without any life cycle events associated to it (no formal approvals, no formal reviews and so forth) then I would suggest you use major versions only.
It basically makes things a whole lot easier and you don’t have to deal with some of the issues that people have with the Major/Minor versioning thing where they turn on Content Approval or Check In/Out
Use Major and Minor versions for content that DOES have a pre-defined lifecycle events
If you have content that has a lifecycle associated with it, for example a formal review process or a major version represents a revision to a customer, then user Major and Minor versions.
There are some real advantages to doing this. Firstly you can restrict the people who can publish major versions so you can control the document life cycle and you can also hide minor versions from users that shouldn’t see them ( I have a post about this next week)
Now if you are going to be enabling Major and Minor versions for lifecycle events make sure that your users understand the difference between a Major and Minor version of a document. Minor versions can be internal drafts whilst major versions can be when a significant event happens.
Should the version number of the document matter?
Should there be a difference between version 4.5 and version 5.5 of a document apart from understanding that they are both minor versions?
I have seen many clients try to establish their document lifecycle based on the version number of a document (all version 1.xx are for board approval, all version 2.xx are for CEO approval, all 3.xx are for shareholder approval). DO NOT DO THIS. Its far too easy for some to publish a major version by accident or screw up the numbering system. If you want to track the lifecycle then create another metadata field and do it that way.
As always there isn’t a ‘one size fits all’ governance model for versions of content in SharePoint. But if you understand the type of content that you have and the business process behind it then you will be able to create governance that will help control unwanted content growth whilst providing the capabilities your users need.
As always feel free to comment and post your thoughts to get some discussion going