SharePoint Version Numbering: How It Actually Works
SharePoint handles versioning automatically. Use that, instead of putting v1, v2, v3 in filenames — it’s cleaner and more reliable.
What it is
Every save in SharePoint creates a version automatically. The version number, timestamp, author, and (if added) check-in comment are all recorded. You can view version history, compare versions, restore previous versions — all without any manual versioning in the filename.
SharePoint supports two version types: major versions (1.0, 2.0, 3.0) for significant or published versions, and minor versions (1.1, 1.2, 1.3) for drafts or work-in-progress. Some libraries use both; others use only major versions. The choice depends on whether your workflow has a meaningful ‘draft vs published’ distinction.
The most common naming mistake is keeping version numbers in filenames anyway — ‘Marketing-Strategy-v3.docx’, ‘Marketing-Strategy-v4.docx’, ‘Marketing-Strategy-v5-FINAL.docx’. Now you have two versioning systems running in parallel: the filename version and SharePoint’s actual version history. They drift, contradict, and confuse. Pick one. SharePoint’s is better.
When to use this
- On any library where you save documents repeatedly.
- When the team is currently using filename-based versioning.
- When you want to enable Compare and Restore features.
- When you need an audit trail of changes.
How to do it
- Open the library and go to Library settings → Versioning settings.
- Enable major versions at minimum.
- Decide if you want minor versions (drafts in progress).
- Set version limits (see L-11) so storage doesn’t grow indefinitely.
- Train users to save in place, not ‘save as’ a new file with a version number.
- Use Check-in comments to describe what changed in each version.
Best practices
- Use major versions for published; minor for drafts. Provides natural lifecycle distinction.
- Add Check-in comments. Version history without comments is just timestamps.
- Save in place, never ‘save as’ for a new version. Defeats version history.
- Pair with Document Status column. Major version + Status = Approved is clearer than version alone.
Common mistakes
- Version numbers in filenames AND in SharePoint history. Two systems drift; users get confused.
- ‘Save As’ creating duplicate files. Each is its own version-history-less orphan. Save in place.
- No Check-in comments. Version history is just dates. Useless for audit.
The File Sanity Kit gives you the Container Method™ — audit, restructure, and future-proof SharePoint without IT admin. The complete methodology, full workbook, and 8-tab Excel planner.
Get the File Sanity Kit — $27 →FAQ
How does Version History work in SharePoint?
Every time a file is saved, SharePoint creates a new version automatically. The most recent version is what users see in the library; older versions are available via the file’s Version History menu (right-click → Version History). You can view, restore, or delete previous versions. By default, SharePoint keeps the last 500 versions per file.
What’s the difference between major and minor versions in SharePoint?
Minor versions are drafts (1.1, 1.2, 1.3) — incremental saves while working. Major versions are published milestones (1.0, 2.0, 3.0) — the versions readers see. Enable major and minor versions in library settings if your team distinguishes ‘working drafts’ from ‘approved versions’. Otherwise, plain incremental versions are simpler.
Why shouldn’t I put ‘v1’, ‘v2’, ‘final’ in SharePoint filenames?
Because SharePoint already tracks versions. Putting v1, v2, v3 in filenames creates parallel files instead of one file with version history — defeating the system. You also end up in ‘Final_FINAL_v2_use_this’ territory within weeks. Trust Version History; keep filenames stable; use a Status column if you need to flag the ‘current approved’ version.
Can I restore a deleted version in SharePoint?
Yes — right-click the file, choose Version History, find the version you want, and click Restore. The selected version becomes the current one (and the previous current version is saved as a new historic version, so nothing is lost). This is the safety net that makes the ‘no version numbers in filenames’ rule actually work.