Manage versions of a shared document
Choose a reference copy, separate drafts from published files and inspect version history before restoring or replacing shared work.
Follow the method ↓
The answer in 30 seconds
Files named final, final2 and final-approved quickly become difficult to follow. A useful system explains where to work, who approves changes and which copy is ready to distribute.
Choose one reference location and a simple naming convention. Before restoring a version, preserve the current state and check how the change will affect collaborators.
Examples to adapt
Compare changed passages instead of replacing the whole file with whichever copy is newest.
Inform affected collaborators and retain the current state before changing it.
Follow the method
- 1Choose the reference
Use one main file or folder. Link to that location instead of circulating competing working attachments. Use one identifier for the document and a separate marker for each version. Distinguish drafts, reviewed copies and published versions. A filename containing “final” says nothing about approval or whether a later requested correction has been included.
- 2Name useful stages
Use a stable title, clear date and meaningful status such as draft, review or published. Avoid unnecessary personal information in filenames.
- 3Inspect history
Where supported, compare versions before restoring. Check author, time and changes without treating history as an independent backup. For a significant change, record the affected passage, its reason and who should review it. Compare content rather than file dates alone: a downloaded or resaved copy can have a new date without containing the latest decision.
- 4Prepare distribution
Export the approved version, reopen it and keep the required references. Remove access that is no longer needed.
Workshop: separate draft, review and published copy
Give each version a date and a clear status, then keep a short change log for edits that alter meaning or figures. When several people review a file, decide who approves the final copy and where it lives. A name such as 'final-v2' is still ambiguous.
Before sending, open the recipient's file and check pages, comments and visible metadata. Archive the replaced version so it cannot circulate as current.
A closer look
Correct a document without losing its history
Fictional example: a file moves through drafting, review and submission. The submitted version must remain identifiable.
| Element | Observation | Decision |
|---|---|---|
| v01 · draft | Working text | Keep changes in a new version |
| v02 · reviewed | Recipient name corrected | Identify reviewer and approval date |
| v02 · sent | Copy actually submitted | Keep confirmation with this version |
A “final” version can become outdated. A number, date and status explain its role better than successive “final”, “final2” and “definitive” names.
Can you correct the copy already sent?
Prepare a new version and record the new submission. Silently changing the retained copy would obscure what the recipient actually received.
A checklist to keep
Use these checks to record your observations. They are a reading aid, not an automatic assessment.
| Check | What to examine | Action |
|---|---|---|
| Reference | Main location | Share |
| Status | Draft or approved | Clarify |
| Recovery | History and copy | Check |
| Distribution | Reviewed export | Archive |
Read the checklist directly in the table.
What to check
Modification time and approval are different.
History depends on the tool and its conditions.
Check the exported file after creating it.
Common questions
Should every file contain a date?
Dates help identify exports and stages, but do not replace a clear shared reference.
Is version history a backup?
It provides a tool-dependent way back; also plan an independent backup strategy.
Sources and documentation
Documentation consulted on . Examples are illustrative; interfaces and results may change.