No more final_final

Hi Reader,

At some point, many of us have created a file called something like:

article_final.docx

Then:

article_final_revised.docx

Then perhaps:

article_final_revised2.docx

And eventually:

article_FINALfinal.docx

I say this without judgment. I have absolutely done versions of this too.

The problem is not that the file names are inelegant.

The problem is that after enough revisions, words like “final,” “new,” “latest,” and “updated” stop telling you very much.

Which one did I send to my coauthor?

Which one went to the journal?

Is “final2” newer than “final_revised”?

What changed between them?

This is essentially a version-control problem: how do we preserve an intelligible order as a file changes over time?

There are much more sophisticated version-control systems, especially for code. But for many of my research files, I use a very simple system of sequential version numbers.

In Project Management for Researchers, I recommend something along the lines of:

projectstub_article_v1.1

projectstub_article_v1.2

projectstub_article_v1.3

In a previous issue, I wrote about the stub name method: using a short, stable name to identify a project wherever it appears.

The stub name tells me which project the file belongs to.

The version number tells me which iteration of that file I am looking at.

Those are two different jobs.

I may also use a meaningful label when the stage itself matters—for example, submitted, R&R, or accepted.

The exact naming convention matters less to me than being able to look at the files later and understand the order of the work.

Version control becomes especially important when other people are involved.

If possible, I prefer to get feedback sequentially rather than send the same file to several people at once and receive several separately edited copies back. I can incorporate one set of comments, save the next version, and then move on to the next round of feedback. That preserves a clearer history of what changed and when.

Of course, sequential feedback is not always practical. If several people need to work on a document at the same time, co-editing the same shared document can be much easier than creating several competing versions that later have to be reconciled.

Either way, I am trying to avoid the moment when I have three edited copies of ostensibly the same draft and have to figure out which changes belong where.

Try this

Open the folder for one active project and look at the files that matter most.

Could you immediately tell which one is the current working version?

Could you tell which version you sent to a collaborator? (Sometimes this information won't be in file names, which is my case, in my case this information lives in my project log, that I shared more about last week).

If several people have commented on it, can you reconstruct the order in which those revisions happened?

If you came back to the folder six months from now, would the names still make sense?

If not, choose a simple versioning convention and start using it with the next file you save.

You do not need to go back and rename every historical file.

The point is to make things clearer going forward.

A suggestion

I would keep the system simple enough that you will actually use it.

For me, version numbers work because I do not have to decide whether something is really “final.”

It is just the next version.

If I make another meaningful round of changes, I create another version.

That can also make experimentation easier. If I want to try a substantial revision and I am not sure it will work, I can create a new version knowing that the earlier one is still there.

And version control does not replace the other organizational practices I have been writing about. I still want the files for a project together in the project folder, with useful subfolders where appropriate. I still use the stub name to make it clear which project something belongs to.

The version number simply answers a different question: Which iteration of this file is this?

As with the other approaches I have been writing about, you may already have a system that works perfectly well for you. The goal is not to use my numbering convention. It is to preserve enough order that you can find the right file—and understand how you got there—without doing archival detective work.

One question for your research: If you opened one of your current project folders a year from now, could you reconstruct the order of the important versions?

Happy projecting,

Shiri

P.S. These days, when I am collaborating, I try to avoid having multiple people independently edit separate copies of the same version at the same time. When feedback can happen sequentially, I find that easier to manage. When we really do need to work simultaneously, I would rather co-edit one shared document and save a new numbered version at a meaningful point than reconcile several competing “current” drafts later.

If this was useful, feel free to forward it to a colleague, student, writing group, or research team. You can find Project Management for Researchers, ordering information, and free worksheets on my Project Management for Researchers page. I also offer talks and workshops on research project management for departments, centers, graduate programs, and research groups.