Version Control and File Naming on Video Projects

A naming and versioning convention that survives a long project, and the specific failures that vague file names cause.

The most expensive mistakes in post production are rarely creative. They are a client approving version four while the editor is working on version six, a final file that turns out to be an earlier cut, an event playing the wrong master, or a language version that was never updated with the last round of changes. Every one of these is a naming and versioning failure, and every one is preventable with a convention that takes an afternoon to agree.

The core problem with the common approach is that words like final carry no information. A folder containing final, final2, finalfinal, final_approved and final_v2_USE_THIS is a folder where nobody can determine the correct file without opening several. Under deadline pressure, somebody will guess, and the guess is what plays at the event.

A convention that works has five parts in a fixed order: project, deliverable, aspect ratio or destination, language, and version. Something like ASTIG_LaunchFilm_16x9_EN_v07 tells anyone what it is without opening it, sorts correctly in a file listing, and cannot be confused with ASTIG_LaunchFilm_9x16_BM_v07. Adding a date in reverse form at the front, when files span months, keeps chronology intact.

Version numbers should be zero padded and should never reset. v07 sorts correctly where v7 does not once v10 exists, and a version number that restarts for a new round creates two files with the same name and different content, which is the exact failure the convention exists to prevent. When a project genuinely branches, for example a client requests an alternative direction, the branch gets a name rather than a reused number.

The distinction that saves the most confusion is between internal versions and client facing releases. An editor may produce fifteen internal versions between two client reviews. The client should see r01, r02, r03, and those release numbers are what appears in feedback and approvals. Mixing the two numbering systems means a client saying they approved v12 while the editor has no idea which release that corresponded to.

Approvals should be recorded against the release identifier in writing, not in a conversation. This matters commercially rather than only administratively: when a client later requests a change that contradicts something they approved, the record of which release was approved and when is what converts a difficult argument into a scope conversation. Mirzaei et al. (2025) argue that project methodologies should be customised to the specific project, and the amount of formality needed here scales with the number of stakeholders rather than the size of the budget.

Project file and media organisation deserves the same discipline as deliverable naming. A consistent folder structure, source media kept separate from working files, generated material logged with the settings that produced it, and a single location for approved brand assets, together determine whether a project can be reopened in two years. For generative work the log of what produced each shot is particularly valuable, because regenerating a matching shot later is otherwise guesswork.

The archive is the part that gets skipped and the part that has the longest consequences. At delivery a project should be archived with the source media, the project files, the approved deliverables, the fonts, the licensed music with its licence documents, and a short readme naming the versions and their status. Storage is inexpensive; reconstructing a project from a delivered MP4 is not possible at all.

For multi language projects the naming convention carries an additional load, because the failure mode is subtle. A Bahasa Malaysia version that was exported before the last picture change looks correct and differs from the English master in ways nobody notices until a client does. Building a delivery checklist that lists every language against every format, and ticking it against the same release number, catches this reliably.

The practical step for a studio is to write the convention down once, put it in the project template, and apply it from the first file rather than retrofitting it at delivery. For a client, the useful request is simply that every file they receive carries a version identifier and that approvals be given against those identifiers. It costs nothing, and it removes the category of problem that most often turns a finished project into a stressful week.

References

Mirzaei, M., Mabin, V. J., & Zwikael, O. (2025). Customising hybrid project management methodologies. Production Planning & Control, 36(9), 1188–1205. https://doi.org/10.1080/09537287.2024.2349231