Version Tracking: Suffix Numbering or a Dated Release Log?
Two simple ways to know which cut is current: numbered suffixes in the file name, or a dated log kept beside the project. A comparison, and the option I suggest for most teams.
Daniel Whitfield · · 6 minutes to read
The problem both options try to solve
Every edit produces more than one file. A rough cut becomes a director's pass, then a client revision, then a legal fix, and somewhere in that chain someone exports the wrong one. Version tracking is the set of rules that stops this. It does not need special software, only agreement about where the answer to 'which file is current' lives.
In the version tracking module I ask teams to look at two approaches that appear again and again on real drives. The first puts the version in the file name, as a number at the end. The second keeps the names plain and records every release in a dated log that sits next to the project. Both work. They fail in different ways, and that difference is what this comparison is about.
Early autumn is a good moment to settle the question, because many teams are starting winter campaigns and holiday deliverables. Choosing a rule before the revisions pile up costs an afternoon. Choosing it afterwards costs weeks of reconciling folders.
Option one: numbered suffixes in the file name
The suffix method adds a version marker to each export, such as a project name followed by v01, v02, v03. Its great strength is visibility. Anyone who opens the folder sees the sequence at once, and the highest number is the newest. There is no second document to open, so nothing can fall out of step with the files themselves.
The weakness is that a number says nothing about meaning. When v07 sits beside v08, nobody knows whether v08 is a client-approved cut or an experiment. Teams drift into names like v08_final and v08_final_REAL, which defeats the purpose. Numbers also collide when two editors work in parallel and both save the next version on the same afternoon.
Used with discipline, though, the suffix is fast and forgiving. It suits small crews, short projects and anyone who dislikes maintaining paperwork.
- Easy to read straight from the folder
- No extra document to keep updated
- Does not record who approved a cut or why
- Breaks down when two editors save in parallel
Option two: plain names plus a dated release log
The log method keeps the file name stable and moves the history into a short document. Each line records the date, the export name, who made it, what changed and its status, for example draft, sent for review or approved. The newest approved line is the answer to the question, and it carries a reason that a bare number never can.
This approach scales better. When a producer returns to a project after six months, the log tells the story in a minute. It also handles parallel work, because entries are added in order of release rather than by guessing the next number.
The cost is upkeep. A log that nobody updates is worse than no log, since it confidently points to the wrong file. It needs an owner, a fixed location and a habit of updating it at the moment of export, not at the end of the week.
Where each option breaks in practice
I have seen the suffix method collapse on a project with three editors and a tight client schedule. Two people exported v12 within an hour of each other, and the delivered file was the wrong one. Nothing in the names could have warned them. A log entry made at export time would have shown the clash immediately.
I have also seen the log method fail, mostly through neglect. A team of five agreed to it in a kickoff meeting and by week three only one person was filling it in. The approved cut was real, but the log lagged two versions behind, so the record contradicted the drive.
Neither failure is about the idea. Both come from asking people to do something extra without making it the natural last step of an export. Whichever option you choose, attach it to an existing habit, such as the moment a file is dropped into the delivery folder.
- Parallel exports expose the weakness of suffixes
- Missed updates expose the weakness of logs
My recommendation: use both, but keep each light
For most production teams I recommend a hybrid that takes the best of each. Keep a simple version number in the export name so the folder reads correctly at a glance, and keep a short release log that records only the moments that matter: sent for review, approved and delivered. The number handles daily work, while the log handles meaning and authority.
Limit the log to those three statuses. Working drafts do not belong in it, which keeps the effort small and the document trustworthy. One named person owns it, usually the producer or the lead editor, and it lives in the project root beside the final exports.
If your team is only one or two people on short jobs, the suffix alone is enough. Once a client, a second editor or a legal reviewer joins, add the log. That is the point where a number stops being sufficient on its own.
- Number in the file name for everyday sorting
- Log for review, approval and delivery only
- One named owner, one fixed location
Setting it up this week
Begin with an inventory of how your last project actually ended. Look at the final folder and ask whether a newcomer could name the delivered file in under a minute. If not, the rule you choose should fix exactly the step where confusion began, whether that was naming, approval or handoff.
Then write the rule on a single page. State the number format, the three log statuses, the owner and the location. Share it at the start of the next project, not in the middle, and review it once the delivery is done to see what the team actually followed.
This is the working method we practise in the version tracking module, using a sample project drive so you can test both options against real revisions before choosing one for your own shoots.
Suffix numbering is quick and visible, while a dated release log carries meaning and approval. Used alone, each has a clear way of failing. Combined lightly, with a number for daily work and a log for review, approval and delivery, they answer the one question every team keeps asking: which file is current. Start with a one-page rule and a single owner, and let the habit settle before adding anything more.
Send us a message
- Call us
- (505) 214-0873
- By email
- [email protected]