Video versioning is the practice of tracking every cut of a project as a distinct, connected version - each with its own feedback, its own changes, and its own status - instead of a folder of files with increasingly desperate file names. This guide covers why versioning fails, how a version stack works, and the workflow that ends "which cut is current?" for good.
Why file names are not version control
Every post team knows the folder: final_v3, final_v3_NEW, final_v3_NEW_clientnotes, final_v4_REAL. The file name is doing the work a version system should do - and it fails at exactly the things that matter:
- A name cannot hold context. It cannot tell you that v3 was rejected because legal flagged the claim at 0:32, or that v4 fixed it.
- A name cannot carry feedback. The notes for v3 live in an email thread that no longer connects to anything.
- A name cannot show status. Nothing in final_v7_revised_REAL tells the producer whether that cut was approved or abandoned.
The failure mode is expensive: editors work from the wrong cut, clients re-review old versions, and "quick fix" rounds become archaeology projects.
The version stack: what a real version system tracks
A version-aware review workflow keeps one canonical stack per deliverable. Each entry in the stack carries:
- The media itself - uploaded once per cut, not re-sent through chat.
- Its feedback - frame-accurate comments attached to that exact cut, staying attached when the next version lands.
- Its changes - what is different from the previous version, so reviewers verify their notes instead of re-watching everything.
- Its status - in review, revised, approved, or superseded. One glance answers "which cut is current and what happened to the others?"
The versioning workflow, step by step
- Start the stack at the first cut. Upload version 1 to the project and share the review link. Everything after this inherits the structure.
- Keep feedback on its source cut. Reviewers comment on v1; those comments stay pinned to v1 even when v2 is uploaded. Context survives.
- Upload revisions as versions, not as new files. Same project, next entry in the stack. The sequence becomes legible to everyone.
- Use side-by-side comparison for decision moments. When a stakeholder asks "what actually changed?", a synchronized compare of two cuts answers it in seconds - no re-review, no guesswork.
- Close the loop before moving on. Mark each note resolved or discussed. The open-note count is the real to-do list, and it should be visible without opening a spreadsheet.
- Record the approval on the exact version. "Approved" attaches to a cut, not to a project. That is what makes the approval trustworthy months later.
The one-question test
Ask your team: "If the editor was hit by a bus today, how long until you know which cut is current and which notes are open?" If the answer involves opening email, the version system does not exist yet.
Versioning inside the edit suite
The review-side stack mirrors what happens in the edit suite:
- Keep the NLE project as the source of truth. The review stack tracks cuts; the project files track timelines. Do not try to make review tools into project management.
- Name exports by version number, consistently. Even with a review stack, predictable export names ("campaign_hero_v4") make the connection between NLE and review tool obvious.
- Close the roundtrip with timecodes. Frame-accurate comments translate directly back into timeline positions - see our editor integrations for keeping feedback close to the timeline in Premiere Pro and DaVinci Resolve.
Common versioning mistakes
- Reviewing by email attachment. Every attachment is a fork. One thread, one version, one place.
- Fixing without re-sharing. If the fixed cut never gets uploaded as a version, the feedback loop has no exit. Always publish the revision.
- Letting reviewers re-review from scratch. Use the change record and comparison view; re-reviewing everything is how approval cycles double in length.
- Skipping the approval step. Without a recorded approval on a specific version, projects die of a thousand "one more look" cycles.
Frooty's video version control is built around this stack - versions with attached feedback, side-by-side comparison, and explicit approval states. For a worked example, see our workflow case study on post-production version control.
Frequently asked questions
What is the difference between a version and a copy?
A copy is disconnected - it has its own name, its own feedback (usually none), and no relationship to the cut it came from. A version is connected: same project, ordered in a stack, carrying its feedback and status. Versioning is the connection, not the duplication.
How many versions should a project go through?
Two to four healthy rounds is typical for a client project: rough, revised, polish, final. If you are regularly at v7+, the problem is usually the feedback loop (vague notes, no approval step) - not the cutting.
Should old versions be deleted?
No. Superseded versions are the project's memory: they show what was rejected and why. Keep them in the stack (they no longer clutter anything), and archive or clean up storage on your own schedule.
Can clients see the whole version stack?
They can when you want them to - a visible history of "you said, we changed" builds trust. If an internal experiment cut should stay private, keep it off the client-facing stack or behind an internal-only link.