Document versions: no more «final_v2_really-final» in file names

Anyone who has worked on a document with other people knows the sequence: report.docx, report_rev.docx, report_final.docx, report_final_corrected.docx, report_FINAL_v2_ok.docx. In the end nobody knows which version is the right one, and someone's corrections are often lost because they were made on an outdated copy. The problem is not solved by more discipline but by a clear method and the right tools.

First question: do you really need several files?

Many modern services already save a version history automatically. Google Docs, Microsoft 365 with OneDrive or SharePoint, Dropbox and many others keep previous states of a file and let you go back. In these cases the best solution is often a single file, always with the same name, and the built-in history to recover what you need.

The advantages are concrete:

• everyone works on the same copy, so there are no parallel versions;
• shared links remain valid;
• you can see who changed what and when.

The limit is that history is not eternal: many services keep versions for a limited period or up to a certain number. For important milestones it is therefore worth creating explicit copies, as explained below.

When you need separate files

There are situations where a separate copy is necessary:

• you have to send the document outside and want to know exactly what you sent;
• a version has been approved or signed and must not change any more;
• you work offline or with people who use different tools;
• you want to keep a state of the document for the long term.

In these cases you need consistent numbering.

Numbering that works

The simplest and most robust system is a progressive number with a leading zero:

2025-04_annual-report_v01.docx
2025-04_annual-report_v02.docx
2025-04_annual-report_v03.docx

Practical rules:

1. The number always goes up, never back, and is never reused.
2. No words like «final» or «definitive»: the next revision will make them untrue.
3. Whoever edits creates the next version, rather than overwriting the one they received.
4. The reviewer's initials can be appended: v03-lb means version 3 with L. B.'s revisions.

To distinguish drafts from approved versions, some people use decimal numbers (v0.3 for drafts, v1.0 for the first approved version). It is useful for technical documents or procedures, a bit excessive for a letter.

The role of tracked changes

Word, LibreOffice Writer and Google Docs can record changes: the reviewer proposes edits, and the author accepts or rejects them. Using tracked changes greatly reduces the need for multiple copies, because the original text and the proposals live together in one file.

One piece of advice: before sending a document outside, accept or reject all revisions and remove comments. Tracked changes stay in the file even if they are not visible in the view mode you chose, and they can show the recipient sentences you had decided to delete.

Separating work from delivery

A structure that works well even for small projects has two subfolders:

Project-X/
  working/
  delivered/

working holds the live file, which evolves. delivered receives a copy, preferably as a PDF, of every version sent to someone, with the date in the name. If six months later someone asks «what did you send us in March?», the answer takes seconds to find, and the PDF guarantees that the content has not been altered by a later edit.

Cleaning up intermediate versions

Piling up thirty versions of the same document helps nobody. When a project is over you can:

• keep the final version in its editable format;
• keep the PDFs of all delivered versions;
• move intermediate versions into a compressed archive or delete them.

Intermediate versions are useful during the work, rarely afterwards.

When the problem gets big

For technical writing, documentation or any content written in a plain-text format such as Markdown, there are version control systems like Git, born for code but excellent for documents too. They record every change with a descriptive message and let you compare two states line by line. They take some learning, but for anyone managing a lot of documentation they pay off quickly.

In short

• If the tool has a version history, use a single file and rely on it.
• When you need separate copies, number them v01, v02 and never use «final».
• Tracked changes replace many copies, but must be cleaned up before sending.
• Keep a PDF of every delivered version, separate from the working file.
• At the end of a project, delete or archive intermediate versions.