A document is rarely a single static thing. It starts as a draft, picks up edits, gets reviewed, gets revised, gets approved, gets signed, gets superseded. Each of those is a different version, and getting versioning right is the difference between knowing exactly what you signed last Tuesday and frantically searching seven final-FINAL-v3.pdf files at 11pm.
Why most document versioning is bad
The default versioning system most people use is filename suffixes:
report.docxreport-v2.docxreport-v2-revised.docxreport-FINAL.docxreport-FINAL-v2.docxreport-FINAL-FINAL.docx
The problems with this:
- No clear ordering. Is "FINAL-v2" newer than "FINAL"? Depends on the writer.
- No record of what changed. You have to compare files manually.
- No indication of which version is canonical. Six "final" files; which is the one currently in effect?
- No easy rollback. Losing the original means losing the option to revert.
Better versioning systems exist, and they don't have to be heavy.
The two-axis problem
Document versions vary on two axes:
- Time: chronological order — which version is newer?
- Branch: variation — drafts, alternate proposals, different audiences.
Pure chronological versioning works for documents that progress linearly (a contract through revisions). Branched versioning works for documents that diverge (a marketing one-pager with three audience-specific variants).
Pick a system that handles your actual document flow. For most business documents, chronological versioning is enough.
A simple chronological scheme
For most documents, this works:
projectname-YYYY-MM-DD-vN.pdf— date and version number.- Increment N for each meaningful change.
- Keep all versions; don't delete the old ones.
- Latest version is always the highest N or the most recent date.
Examples:
acme-contract-2026-05-07-v1.pdf(initial draft)acme-contract-2026-05-07-v2.pdf(after first review)acme-contract-2026-05-09-v3.pdf(final signed)
This is simple, sortable, scannable. Don't overthink it.
When to bump major vs minor
For documents that go through many small changes:
- v1.0: initial release.
- v1.1: minor revisions (typos, formatting).
- v2.0: substantial revisions (new sections, changed terms).
Use this when documents are explicitly "released" — published reports, public policies, formal templates.
For everyday documents, plain v1, v2, v3 is enough.
Status indicators
Add status to filenames for visibility:
- DRAFT: not yet reviewed.
- REVIEW: out for review.
- APPROVED: signed off.
- SUPERSEDED: replaced by a newer version.
Examples:
acme-contract-2026-05-07-v1-DRAFT.pdfacme-contract-2026-05-07-v2-REVIEW.pdfacme-contract-2026-05-09-v3-APPROVED.pdf
When you find a folder with one APPROVED file and several SUPERSEDED ones, you instantly know which version is current.
Versioning for collaborative documents
When multiple people edit the same document, filename versioning falls down:
- Two people edit v2 simultaneously, both save as v3 — conflict.
- Someone uses a different naming convention — chaos.
- The "official" version drifts as everyone has their own copy.
For collaborative editing, use a tool with native versioning:
- Google Docs: every change is a version. Restore any past state.
- Microsoft 365: similar version history in OneDrive.
- Git: powerful but text-oriented. Works best for plain text and Markdown documents.
- DMS (document management systems): version control as a first-class feature. See document management systems explained.
The principle: pick the right tool for the format. Spreadsheets and word processor docs in cloud-collaborative tools; PDFs in a DMS or filename versioning.
Versioning PDFs specifically
PDFs are a published format — they're not really meant to be edited collaboratively. The right pattern:
- Keep the source document (Word, LaTeX, Google Doc) as the editing version.
- Export to PDF whenever you publish a version.
- Name PDFs with version numbers matching the source.
- Keep all PDF versions; archive old ones once they're superseded.
This way the source has full editing history (in Google Docs version history, in Word's track changes, in git for LaTeX), while the PDFs are immutable snapshots.
For more on the source/PDF pipeline, see how to convert Word to PDF and PDF vs Word.
What to put in the version metadata
Beyond the filename, include version info inside the document:
- A footer with version number and date on every page.
- A revision history table at the front: version, date, author, changes.
- Document metadata: title, version, modified date — fillable in most word processors.
When someone hands you a PDF without context, the document itself should tell you what version it is.
Comparing versions
Most version disputes come down to "what changed?" A few habits make this fast:
- Track changes in the source. Word, Google Docs, LaTeX with
latexdiff. - Compare PDF versions when only PDFs survive. See how to compare two PDFs.
- Save the diff when versions are formally released. A PDF showing "what changed in v3 vs v2" is useful for audit.
Retention rules
Don't keep every version forever — but be deliberate about deletion:
- Active project: keep all versions.
- Closed project, not regulated: keep latest version plus the immediately previous version. Delete older drafts.
- Regulated documents (legal, tax, medical): keep all versions per the retention requirement, even if intermediate.
- Templates: keep latest released version, archive older releases.
A documented retention policy beats a "we keep everything" policy that no one cleans up.
When to start fresh
Sometimes the right answer is a new document, not a new version:
- The structure has changed substantially. A v15 with a totally different table of contents than v1 is misleading; start a new document.
- The audience has changed. A document originally for one client now serves another; fork rather than version.
- The legal status has changed. A signed contract is immutable. New versions go in a related but separate document, often as an amendment.
Tools that help
- Cloud storage version history: Dropbox, Drive, OneDrive, iCloud all retain past versions for 30+ days. Free, automatic.
- DMS: dedicated version control with longer retention. See document management systems explained.
- Git: works for any text-based document (Markdown, LaTeX, code). Overkill for personal use; excellent for technical writing.
- Time Machine / File History: OS-level backups give you periodic snapshots, useful for recovery if not for everyday version comparison.
Avoid these patterns
final-FINAL-FINAL: just use a number.- Versions in email subjects: works for one round, fails on the third reply.
- Putting the version in the document content but not the filename: fine until someone forwards the file and the recipient doesn't know which version it is.
- Renaming the canonical file with each new version: makes existing references break. Add a version, don't rename.
- Deleting old versions immediately: regret strikes when someone asks "what did v2 say?"
Conclusion
Good versioning is about sortable, scannable filenames; clear status; preserved history; and a tool that fits the document type. Source documents in collaborative tools with native version history; PDFs with filename-based versioning and never-overwritten archives. For PDF tasks specifically, Docento.app handles compression, signing, and metadata stripping in the browser — preserving versions privately. For related topics, see document management systems explained and how to organise digital documents.