Document version control template
A document version control template showing how a draft moves from minor versions (0.1, 0.2...) through review, gets a whole number only at formal approval, and how later revisions supersede the version they replace.
How it works
Fix your decimal and whole-number convention
Decide, and write down, that draft versions take a decimal and issued versions take a whole number, or pick another convention if yours differs. The exact scheme matters less than that it is stated once and applied everywhere a version number appears, including headers, footers and the register.
Decide what counts as a new review cycle
Set the rule behind 'Increment the minor version': does every markup pass bump the number, or only a re-issue of the draft after changes are made? Teams that increment on every comment thread end up with drafts in the twenties; teams that increment only on re-issue keep the count meaningful.
Set the rule for what earns a major version
Formal approval is the trigger this chart uses at 'Assign major version 1.0', but some organisations also bump the major number on a substantial rewrite even without a full re-approval. Pick one rule and apply it consistently, since a mixed rule is what makes version numbers stop meaning anything.
Define what happens to a superseded version
At 'Mark the previous version superseded', decide where that prior version lives afterwards: archived in the register with its supersede date, or removed from the controlled location but retained for a fixed period. Either is defensible; an undocumented answer is not.
Decide how a post-publication change is numbered
At 'Reopen the document at the next version', fix whether a change to an in-force document restarts the minor-version drafting cycle at the next whole number or resumes decimals off the last major number. This is the rule most teams forget to write down until the second revision is already underway.
Frequently asked questions
What is the difference between a minor and a major document version?
A minor version, written as a decimal such as 0.1 or 0.2, marks a draft still inside internal review that has not been approved for use. A major version, written as a whole number such as 1.0 or 2.0, marks a version an approver has actually signed off and that has been published to the controlled location. The distinction exists so that citing 'version 2' always means an issued document, never a draft that happens to be on its second review cycle.
Does every round of review comments create a new version number?
That is a rule your organisation sets, not something the numbering scheme dictates on its own. Many teams increment the minor version only when a draft is re-issued for another round of review, not on every individual comment, so the number stays a meaningful count of drafting cycles rather than a count of edits.
What happens to a version once it is superseded, is it deleted?
No. A superseded version is marked as such in the version history register and normally kept for a defined retention period, since it is the record of what was in force on a given date. It is withdrawn from the controlled location so nobody works from it by mistake, but deleting it outright removes the evidence an auditor or an incident investigation might later need.
How is this different from a document control process or a revision log?
The document control process flowchart at /templates/document-control-process is the full lifecycle a document goes through, request, drafting, review, approval, issue, distribution and periodic review, and this template assumes that lifecycle already exists. A revision log is a flat register of individual changes, who edited what and when. This chart sits between the two: it is only the mechanic that decides which number, minor or major, a document is entitled to carry at each point in that lifecycle.