What's in a version number? (Or: Musings on backwards compatibility)

The method I use and often encourage other people to use is version control latex and csv files and python scripts in git, which can do everything MS office does. This has worked exactly zero times, so what I encourage others to do instead is…

Use the format filename_YEAR_MO_DY_username.xlsx. This has the benefit that Lexicographic ordering every OS does in its file explorer is the same as chronological order, so it acts as a crude version control system.

Been fighting the same fight. Anytime someone sends me a file with a with _FINAL_XYZ_approved_modified_etc I delete all that stuff and increment the version number before I send it back to them. Folks eventually catch on. It helps that I'm the one writing procedures for the document management people to follow. One surprising (to me) argument against was that people don't like it when the first version we produce (meaning our group throws it over the wall to another group) is higher than version 0. I shrug and say, it's just a number.

Sure there's lots of more robust ways to track versions. But the above simple convention is a step function in quality of life while requiring hardly any work.

There is a ton of money to be made if one can create a vcs for office.

The notion of "final" is very much an emotional, kind of mindset, one. In any kind of research there's this impending mental final frontier, which is often tied to some concluded stage. It's similar somewhat to a "release", but as such there's no real product notion.

Also, the "final" is usually what one may submit for a review, then the remarks may just be relating to _that_ "final", quite logically creating another train-car in the filename.

I also encouraged colleagues to date-version in such cases, but this eventually leads to multiple date-stamped train.

A curious thing is that rarely the researchers get back to those older versions, they just keep them and as easily forget about why they kept them, once the reasearch is pushed out.

So my solition back then was letting them do their thing as they see fit within the project area till the conclusion, then round out all the related artifacts and stuff them into a repo. Any revisions then get added to that repo, as well as any remarks about what/when was submitted to where/whom. Loosely structured and messy, but hopefully internally relevant and consistent.

The main goal - preserve first, then rearrange, if needed.

I date all my files.

    filename-yyyy-mm-dd-n.xlsx

I don't worry about anything beyond that. The file system manages snapshots without my attention, messy software like Box or SharePoint can manage versioning if files need to live there, the OS can try to manage metadata, all of that is separate from my needs: fast easy access to old/new versions of documents.

When I'm working on something and I feel like I'm about to make major changes, I save with today's date. If I want to know what I presented to people at a specific meeting, I look up the meeting date. If I want to branch or add a version or tag (final_FINAL_V2) then I'll rename the file, but I always update the date.

Just put "new" in front, its what is popular here. lol.

I think that in some cases, the multiple finals are at least semi-ironic. For my fiction writing, I number each draft with -dn at the end of the name and leave it at that. I will occasionally have modified versions of that when it goes out on submission (most commonly -d5-anon for journals that require anonymous submissions, or -d5-journal for journals that have idiosyncratic formatting requirements (some journals want the cover letter included with the story, some want single or 1½ spacing, one asks for a brief note on the creative process at the end).

Filename-[[ISO8601DATE]]-[[sub]]-initials(.extension)

You use the date only part of ISO8601, because it's the standard for dates. E.G. 2021-10-08 this is a serial number. They'll want to know who last touched the file, but the subversion is next. This can either be a letter, or better, another small number. Field size depends on the wor... most productive day.

filename-2021-10-08-01-YOU.txt

Note, all version fields are always full-width (padded).

Interestingly, dhouston in his YC Dropbox application mentioned this exact scenario. A decade later, it seems folks still do not trust tools with built-in capability to restore across various versions.

yc: Please tell us something surprising or amusing that one of you has discovered.

dhouston: The ridiculous things people name their documents to do versioning, like "proposal v2 good revised NEW 11-15-06.doc", continue to crack me up.

https://archive.is/vZnkB

Using a *simple* version control system with a *simple* graphical user interface might go a long way to convincing them to use versioning. I would suggest SVN with TortoiseSVN, and would most strongly argue against GIT. Yes, all the cool kids use GIT. For simple users, SVN is something that's easy to understand and that they cannot get wrong. They are also highly unlikely to need to rebase their .xslx files.

We managed to get the sales people to use SVN for their work on proposals. Now the proposal is simply called "project name/proposal.docx", instead of having dozens of documents with unclear provenance around, possibly over multiple machines.

In addition to that you can lure them in with the option to roll back to old data, and central backups.

You've had a bunch of answers, not sure if this is of value.

The problem is cultural. You will not shift that.

I infer Windows.

Create a scheduled task that starts frequently but not if another instance is running. The task runs a powershell script.

The script creates a FileSystemWatcher tracking the "HEAD" spreadsheet.

On write, it copies the file, appending a date-time.

Users do nothing in particular. But they visibly see backups being created. So they know they can just work on the current file and not rename it.

This is horrific macguyver shit, but it's attuned to the customer needs, can be distributed as a single file that creates the scheduled task, and requires near-zero user behaviour modification.

Avenues of further development: debounce, so 14 saves in a single minute don't create 14 backups; toast notifications using BurntToast so that errors are not silent