Naming Files for Version History

May 07, 2013

Hi All!!

Been "hanging out" here for years, but finally getting to put all my ideas into practice.  

I'm working on trying to create standards for our documentation and wondered how you are naming your files and how you differentiate "versions" of those files.

Do you just use the date? Do you use a number of some kind?

I searched, but didn't see anything in the archives.

Thanks!

Laura

6 Replies
Sheila Bulthuis

I version things by appending to the file name.  I use "D1" D2" etc while I'm working on drafts - I like to version fairly often in case of file corruption, etc.  (and if I'm going to try something I'm not sure will work, I save, version, THEN try it, so I can always revert back if needed!).  Once it goes for review (to the client) it becomes V0.1.  If we're doing iterations those are V0.2, etc.  Once we have a final version, it's V1.0.  Changes made after that are versioned according to whether they're a major (whole number) or minor revision.

 

I started doing that way because one of my clients, who is highly regulated, needed it to be very clear what were published versions vs. drafts etc. It's worked pretty well so i try to do it now for all my projects.

 

I'm interested to see how others do it!

Joseph Olive

Here are a few tips that I find handy:

When dating a file try using the format YYYYMMDD (i.e. 20130115 for January 15th, 2013).  That way anything you’re working on that spans the New Year will still sort in your folder in the right order.  When using version in the title (i.e. v01, v02, etc.) try and account for how many versions you’ll likely have by using a zero in front of single digits for sorting purposes as well.  That way, v09 lines up before v10, if you get that high.  Windows also keeps track of last modified date and creation date in the “details” view of any folder.

Personally, I try and limit the amount of versions that I save to major changes only.  Otherwise managing them all over time can be difficult. 

If available, SharePoint has version control built in and can be managed a number of different ways depending on your needs.

Scott Hewitt

Hi Laura,

Everyone has something that works for them - here is ours. We combine our naming structure and version control.

Example file: RP 4001 Course Script v1.0.ppt

  • RP 4001 is the project job code
  • Course Script is the filename - change as required
  • v1.0 is the version number

We start every document at v1.0 and increment by 1 if there is any change. To control any changes we use cover sheets and update with a short note with what has been updated. It might seem a lot but it has saved a lot of time if we return to the document at a later point.

Using job codes help as each client has its own set of numbers - for example. So we know that all of Mega Corp's projects are in the RP 4000 folder.

Hope this helps,

Scott

Steve Flowers

We usually try to keep things simple. I really like Bruce's method and tend to place a date at the end of the file name when the file reaches the end of a phase or increment. Another thing we usually recommend is not using spaces in file names or folder names, we also avoid using upper case letters in file / folder naming. Consistency is easier if the rules are easier

For versioning, we've seen folks save a version for every major revision (often saving multiple different files each day). When you're on a static file system, this is a safe way to go but I'd come up with a purging practice -- these files can take up a lot of space. If you're keeping several old versions, you might consider moving the unused versions to an *archive* or *old* folder. This will prevent accidental opening and adding new work to an older version (rare, but it happens to the best of us -- oops)

When working at home, I always have files in version control of some type. Whether that's SVN, GIT, or Dropbox. This way I always have a way to revert. This keeps me from having to save incremental versions since commits are date tagged and in SVN and GIT, commit notes are attached to indicate the change.

This discussion is closed. You can start a new discussion or contact Articulate Support.