What document version control means
Document version control means three things hold at once. Every change produces a numbered version, and the old ones are kept. One version is marked current. And anyone who needs to can open an older version, or make it current again, without asking the person who made the change.
final_v3_FINAL.docx fails all three.
There are three ways to get it, from simplest to strongest:
- A naming rule and a version table. Any file, any tool, no software. The people have to follow it.
- The version history built into Google Docs, Word and SharePoint. Automatic, but tied to one file in one place, with limits on how far back it reaches.
- A page where every version has its own address. Each version is a link you can send, one is live, going back is one step. Only for work that ends up as a page.
Pick by who needs to see which version. Only you: the naming rule. A colleague editing the same file: the built-in history. A client or a team who must look at a specific version and say what is wrong with it: an address per version.
One document, five versions
A made-up but ordinary case. A designer writes a one-page proposal for a bakery. Over ten days it goes through a first draft, a colleague's price correction, the version sent to the client, the client's cut of one section, and sign-off.
| Version | What happened | Naming rule | Google Docs or Word | Page with versioned addresses |
|---|---|---|---|---|
| 1 | First draft written | bakery-proposal_v0.1_2026-09-14.docx in the project folder | One file. History starts recording automatically | Version 1 published; it gets an address of its own |
| 2 | Colleague corrects the price | Saved as _v0.2_2026-09-15; v0.1 stays | Edit lands in the same file; the colleague needs edit access. Name the version "price fixed" | Version 2 published with the note "price fixed". Version 1 stays at its address |
| 3 | Sent to the client | Renamed to _v1.0_2026-09-16; a row added to the version table | Name the version "sent to client". Send a copy or a view link, not edit access | Send the address of version 3. The client opens it without an account and leaves remarks on the page |
| 4 | Client cuts the timeline section | _v1.1_2026-09-19 | Delete the section; history keeps it. If the cut was wrong, restore "sent to client" | Version 4 published from the remarks. If the cut was wrong, roll back to version 3 |
| 5 | Signed off, date updated | _v2.0_2026-09-24; status "approved" | Name the version "approved". Stop editing this file | Version 5 live. Versions 1 to 4 keep their addresses |
The naming rule costs a rename and a table row at every step and breaks the first time somebody forgets. The built-in history costs nothing until step 3, where a link to a file the client can edit mixes their changes into yours. The page costs the most up front, because the proposal has to be a page, and then every step is one action with a link at the end.
Name and number versions
If the file lives in a folder, one rule is enough for a team of five:
<document>_v<major>.<minor>_<YYYY-MM-DD>The minor number goes up on every internal round. The major number goes up when the document crosses a boundary: sent to the client, approved, published. Versions below 1.0 have never left the room. This is the convention SharePoint uses for its own versioning: a major version is "a milestone, such as a file submitted for review or publication", a minor version is "a work in progress".
Three details make it survive a real week. The date is year first, so files sort in any
folder view. The word "final" is banned, because v2.0 can become v2.1 and "final"
cannot. Old versions are never overwritten: save as, never save.
And one version table, at the top of the document or as a sheet in the folder:
| Version | Date | Author | What changed | Status |
|---|---|---|---|---|
| 0.1 | 2026-09-14 | Dana | First draft | draft |
| 0.2 | 2026-09-15 | Sam | Price corrected on page 1 | draft |
| 1.0 | 2026-09-16 | Dana | Sent to client | in review |
| 1.1 | 2026-09-19 | Dana | Timeline section removed at client's request | in review |
| 2.0 | 2026-09-24 | Dana | Date updated, signed off | current |
Keep "what changed" to one line, and write what was changed rather than why. The why goes in the email.
Use the history you already have: Google Docs and Word
Steps and limits as Google's and Microsoft's help pages state them, checked on 2026-09-28.
Google Docs
- At the top right of the document, click the last-edit note to open the history.
- To mark a version, click More next to it and choose "Name this version". Up to 40 named versions per document.
- To go back, choose the earlier version and click "Restore this version". Nothing is deleted.
Two limits. "To browse earlier versions of a file, you need permission to edit that file", so a client with a view-only link cannot see the history. And "the revisions for your file may occasionally be merged": unnamed versions are not a guaranteed record. Name the ones that matter.
Word on OneDrive and SharePoint
"Version history in Microsoft 365 only works for files stored in OneDrive or SharePoint."
A .docx on a desktop or in an email attachment has no history.
- In Word, click the file's title at the top and choose "Version history".
- Pick a version from the list. It opens in a separate window.
- Click "Restore". The version you replaced stays in the list.
The limits depend on the account. For a personal account, one Microsoft page says the last 25 versions, another says 30 days; assume the tighter one. For a work account the number "will depend on your library configuration", and an administrator may have turned versioning off. SharePoint is the strongest: on by default for a new library, 500 versions, numbered 1.0 and 1.1 the same way as the rule above.
What none of these give you: a version the client can mark up without being able to edit it, and a version that stays at the same link after you have moved on. For that the document has to become a page.
When the document is a page
A proposal, a report, a deck, a landing page: much of what goes back and forth with a client ends up as a web page. Birta versions the published page; your Word file stays in Word, and your agent turns it into the page and publishes it.
Every version has its own address. When the agent publishes, the project address shows the new version, and the version gets a permanent link of its own. Send that link and the recipient sees exactly that version, however many more you publish. It opens without an account and is not indexed by search engines.
One version is live, and a draft in progress is not it; the draft has its own address for the people working on the project.
Going back is one step. A rollback makes an earlier version live again. It creates no new version and deletes nothing, and no version's link changes.
Remarks live on a version. Whoever opens a version's address can pin a remark to an element, and the threads keep their numbers, so "do number 3" means one thing. The agent reads those threads and changes the same draft; it cannot post or close them (how the remarks work, how to run the round).
What changed is a note, not a diff. Each version carries a one-line note such as "price fixed". There is no side-by-side comparison of two versions.
Across 2,400 projects published on Birta, the median project has three versions, one before it goes public and two after, and 11.0% rolled back at least once, typically one version and within the hour. That is one host and mostly small sites written by an agent, not documents in general. But the common case it shows, a quick correction in the same sitting, is exactly what a permanent address per version is for.
Publish the document as a page
Every change becomes a version with its own link, one of them is live, and going back is one step.
When you need version control software
Four signals say the three setups above are no longer enough:
- Approvals with a signature. A version cannot become current until a named person signs it off, and the system must record who and when.
- An audit trail somebody else will inspect. A regulator, a certifying body or a lawyer will ask for the history.
- Retention rules. Versions must be kept, or destroyed, on a schedule you do not control.
- Volume. Hundreds of documents across dozens of people.
If one is true, look at categories rather than a ranking: document management systems, quality or compliance systems for regulated work, contract lifecycle tools, and the storage you already pay for. A Microsoft 365 team often already owns SharePoint's 500-version history. If none is true, the purchase buys administration, not control.
Five rules for a team
- One current version, in one place. A file in the shared folder, the live Google Doc, or the live page. Not an attachment.
- Number it before it leaves the room. Anything sent to a client gets a major version number and a row in the table first.
- "Final" is not a version. Use a number. The next version is always allowed.
- Write one line about what changed. In the table, in the named version, or in the note on the published version.
- Keep the old ones and stop worrying. When someone needs an earlier version, they need it back within the hour, not a description of it.