Document version control best practices

A worked example, stage by stage

1. The scheme starts before anyone reviews anything

   "Assign initial draft version 0.1" happens immediately after "New document drafted," before "Circulate draft for internal review" or "Reviewer evaluates the draft": the decimal scheme is fixed at row two, not invented partway through the first "Changes required?" decision.

2. Rework increments, it never renumbers

   "Increment the minor version" and "Revise the draft against comments" loop back into review on a branch labelled "Re-review" before "Submit final draft for approval" and "Approver reviews the final draft": the same decimal rule holds through every pass, so citing draft 0.3 still names one exact copy.

3. One decision draws the major-versus-minor line

   "Approved for issue?" is the only row with a route to a whole number: the Approved branch reaches "Assign major version 1.0," while Rejected loops back to "Increment the minor version," then "Update the version history register," "Publish the approved version" and "Mark the previous version superseded" fix that decision in a File row before anyone reads the new copy.

4. A document that needs no change still gets a mark

   "Change requested after publication?" is answered even when the answer is No: that branch ends at "Current version remains in force," a named outcome rather than an absence of activity, while Yes reopens the document at "Reopen the document at the next version" instead of starting a second copy alongside it.

How it works

1. Freeze the numbering scheme once real documents depend on it

   Treat a change to the scheme itself (moving from whole numbers to semantic versioning, or redefining what a decimal means) as a project, not a tweak: it invalidates every existing cross-reference, training record and prior audit citation. If a flaw turns up, document the exception going forward rather than renumbering the library.

2. Put version, date and approver in one fixed spot on every template

   Choose a single position (header or footer) and bake it into the document template so every author uses it without deciding. A version number in a file name or in document properties does not survive a printout, a screenshot or an email forward; one printed on the page does.

3. Give the "current" version a lock or checkout convention

   Decide who may have the current version open for editing at once, and how a second author finds out someone already does: a checkout flag in the register, a locked file, or a single canonical live copy where only one save can win at a time. Without this, two approved edits landing on the same version is not a hypothetical.

4. Write the major-versus-minor rule down before the first document needs it

   Specify, in the same document that defines the numbering scheme, exactly what triggers a whole-number step: formal approval alone, or approval plus a substantial rewrite. A team that decides this case by case ends up with two different documents both called version 2.0.

5. Record every periodic review, including the ones that change nothing

   Give the review step a decision shape with a labelled "no change" exit that writes a dated entry to the register, the way "Change requested after publication?" reaches "Current version remains in force" instead of simply doing nothing. A missing entry should mean the review did not happen, not that nothing happened during it.

6. Let one canonical live copy remove the lock problem entirely

   Open the document as a QueryChart chart instead of a set of files passed around by email, and there is only one current version to edit: every save is captured as a new entry in the Change Log automatically, so a checkout convention has nothing left to enforce. See /features/version-control.

Frequently asked questions

What's the single biggest document version control mistake to avoid?

Treating the scheme as fixed only until someone finds a reason to change it. Renumbering an existing library (even to fix a genuine flaw) breaks every cross-reference, training record and audit citation that named the old numbers, and that cost almost always exceeds the cost of living with an imperfect scheme. Fix problems going forward with a documented exception, not by touching what is already issued.

How do I stop two people editing the same "current" version at once?

Either add an explicit checkout convention (a flag in the register showing who has the document open, so a second author knows to wait) or remove the possibility structurally by keeping exactly one canonical live copy instead of files passed around by email or a shared drive. QueryChart does the second: every document is one live chart, every save versions automatically, and there is no second copy to fork. See /features/version-control.

What should count as a major version versus a minor one?

There is no universal rule, which is exactly why it has to be written down before the first document needs it rather than judged case by case. A common convention ties the major, whole-number step to formal approval alone (every draft revision in between, however substantial, stays a decimal), so "how big was the change" never has to be argued in the moment a version number is assigned.

Do I need to log a periodic review that found no changes needed?

Yes: an unrecorded review is indistinguishable from a review that never happened. Give the review step in your process a decision shape with a labelled exit for "no change needed" that still writes a dated entry to the register, the same way a chart's decision row records every branch it takes, not just the ones that lead somewhere new.