Photo Version Control: How to Find the Current Edit

Why v2_FINAL_final.jpg happens to every workflow eventually

The filename-as-version-control pattern isn't a mistake anyone makes on purpose. It's what happens by default when a tool has no other place to record status. You export a round of edits, you call it wedding_v1.jpg. The client asks for two changes, you export again — wedding_v2.jpg. They approve it, but then remember one more thing three days later. Now what do you call the file: wedding_v3.jpg? wedding_v2_final.jpg? Six months later, when the album vendor asks for the approved images, the answer is buried in an email thread, not in the filename.

The underlying issue is that a filename can only encode one thing at a time — usually a sequence number — while "which file is current" actually depends on three separate facts: which version was produced most recently, which version was reviewed most recently, and which version was approved. Those three don't always point to the same file. A photographer can produce v3 while the client has only reviewed v2 and approved v1. A filename has no way to hold all three states at once, so whichever one gets typed into the name wins — and it's usually wrong for at least one of the three questions.

The moment two people can each look at a folder and give a different honest answer to "which one is current," the filename has already failed as a version-control system — no amount of extra typing (_ACTUALLY_final, _use_this_one) fixes that, because the problem was never the word choice.

Where 'current' actually breaks: four handoff points

Version confusion doesn't happen randomly across a project — it clusters at specific handoffs, and each one breaks a different way.

• Photographer to retoucher. The retoucher works from whatever file was last exported, which may not be the file the client most recently commented on. Their edits land on the wrong base image.
• Retoucher back to photographer. The retoucher's output needs a name and a place, and if it goes into the same folder as everything else, it's now indistinguishable from a draft unless something marks it as reviewed.
• Photographer to client. The client sees a gallery link or an attachment, gives feedback, and that feedback needs to attach to the exact frame they saw — not to "the wedding photos" as a category. Generic feedback on a specific version is a common source of the wrong edit getting revised.
• Client to approver. On team or agency work, the person giving feedback and the person with authority to approve are often different people. A client contact can love a version their creative director later rejects, and if that rejection doesn't overwrite the "approved" status visibly, both versions keep circulating.

Each of these is a place where a status — draft, in review, approved, delivered — needs to travel with the file, not live in a person's memory or a Slack message that scrolls away. Teams that track approval status in a general-purpose tool instead of an image-aware one run into this directly; see our breakdown of using Notion or Airtable for photo approval tracking for where a spreadsheet-style tracker keeps up and where it stops working at the image level.

A four-state model that replaces the filename as the source of truth

The fix isn't a better naming scheme — it's moving version status off the filename entirely and onto a field that updates in place. Four states cover almost every photo workflow:

The key property of this model is that the file itself never has to be renamed to reflect its state. The status is metadata attached to the file, so "which one is current" has exactly one answer at any moment: whichever version carries the Approved state, or — if nothing has been approved yet — whichever one is In review. Nobody has to remember; the system can just answer the question when asked.

This is the same reasoning that pushes larger teams toward a proper digital asset management layer. If you're weighing whether your team actually needs one or whether a lighter approval workflow covers it, we cover that trade-off directly in do you need a DAM, or just an approval workflow — the short version is that a four-state model like this one is usually enough until you're managing reuse across many campaigns, not just approval on a single shoot.

Naming conventions that survive a handoff (without the word 'final')

Even with status tracked separately, files still need names — for exports, for backups, for the moments a file leaves your system entirely (a print lab, a stock delivery, an offline archive). The rule that keeps a filename useful without pretending to be a status field: encode facts that don't change, not facts that do.

Notice what's missing from the right-hand column: the word "final" doesn't appear anywhere. That's deliberate. "Final" is a claim about status, and status is exactly the thing that changes — sometimes after a client remembers one more note three days post-approval. A frame number and a sequence number never lie, because they never had an opinion to begin with.

A worked example: one photo, four exports, one approved

Walk one frame through a real revision cycle and the four-state model stops being abstract. Say a corporate headshot goes out for review on a Monday.

Export 1 (v1) goes out Monday morning, status In review. The subject asks for softer retouching on Tuesday — that feedback attaches to v1 specifically, not to "the headshot" generically, so the retoucher knows exactly which file and which note to act on.

Export 2 (v2) ships Tuesday afternoon with the requested change. v1 automatically flips to Superseded — it's still sitting in the history if anyone needs to compare, but nothing points a retoucher, a client, or an automated delivery job back at it. HR, reviewing separately, asks for a color correction on v2 Wednesday.

Export 3 (v3) addresses that note. The subject approves v3 Wednesday afternoon. Status: Approved. At this point, three exports exist, two are Superseded, and exactly one — v3 — is the file every downstream system should pull: the delivery gallery, the HR system, the print vendor.

Export 4 shows up two weeks later, when the subject changes their mind about the crop for a conference bio. It doesn't overwrite v3's record — it becomes a new version with its own review cycle, and v3 stays the approved-and-delivered file of record until v4 clears its own approval. Four exports, one unambiguous current file at every point in the timeline, and a full history of who asked for what and when — none of it stored in a filename.

Making 'current' a system fact, not a memory

The teams that stop having this problem share one habit: they treat "what's current" as a question the system answers, not a question a person has to hold in their head. In practice that means three things happening automatically, without anyone remembering to do them by hand.

First, a new export doesn't overwrite or rename the previous one — it creates a new version and marks the old one superseded, so the review history stays intact even after the file everyone's looking at has changed. Second, feedback attaches to the specific version it was given on, so a comment made on v2 doesn't silently get read as applying to v3 once a new export lands. Third, approval is a single action taken by one named person on one specific version — not a status that gets inferred from an email that said "looks good" three replies deep in a thread about something else.

None of this requires enterprise software. It requires a review process where status and version are tracked as data rather than typed into filenames by hand — which is a smaller ask than it sounds like, and the payoff is that "which one is current" stops being a question anyone on the team has to answer from memory.