I work with a bunch of biologists and one of my jobs is to find a solution for the filename_final_final_FINALNEWEST.xlsx problem... thinking about how to convince people to use something like a versioning system, or just use a single number, e.g. filename-4.xlsx, and write a tool to collapse all those finals into a number, e.g. filename_final_final.xlsx into filename_final2.xlsx...
I'm still not sure if it's the best way to go about it though. But I think version numbering is still much stronger than tacking multiple "finals" to a file name. Happy to hear what others are doing!
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.
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.
I've run into that too. People attach a lot of value to version numbers, even for internal projects/releases, and it's hard to get their perspective shifted to just accept it as communication tool (e.g. semver).
There's nothing special about 1.0.0 vs 2.0.0, it just means there was a breaking change and you may need to do some work when upgrading.
And a major, awesome feature might get released as 1.15.25 -> 1.16.0, that's OK. (marketing hates this)
Just make everybody happy by using MARKETING.BREAKING.FEATURE.BUGFIX versioning, and then personally ignore the leading number (since it is actually meaningless). Or just have a separate marketing version. I'm not even (just) joking. Notice that this is not unlike Windows (Windows 7 through 8.1 were NT 6.1 - 6.3, then 10 went crazy even on internal versioning) or Solaris (which made it from version 2 to 11 on internal version 5.x).
This is essentially my plan for releases of the finl app. It'll have a three-part semantic version number (which I suspect will be 1.x.y forever) and then a “marketing” name indicating the major feature checkpoints, for which I'm going to name releases by element.¹ I figure I'll be dead long before I ever hit Ununennium and if anyone still uses finl by that time it will be someone else's problem.
⸻⸻⸻
1. It would be nice to have some mathematical theme, but I don't know of anything that's (a) sufficiently well-known (going with, say, famous mathematicians wouldn't work because the list is not necessarily agreed upon nor is it obvious to the casual user whether Riemann comes before or after Weierstrass), (2) non-numeric (so no fibonaccis or primes) and (iii) of sufficient length (so no platonic solids or named polygons).
SemVer is best IMO. Though I can see why it's hard to define exactly what constitutes a breaking--therefore major version--change when talking about user visible products or services.
Personally I'm frequently rug pulled by breaking changes in patch updates.
Imo, semver is just a way for lazy devs to break backwards compat and feel ok about it.
Which would be fine if they maintained their old versions, which of course they don't, so what's the point of semver? All the breaking change version change means to me is you've forked your library and left me holding the bag.
I either have to update my code to accommodate your changes or I need to change your code to accommodate security issues.
And fuck me sideways if I have you as a peer dependency.
Again, which version of semver are you talking about?
And yes, of course they would have, but at least they wouldn't be able to lie about what theyre doing.
There is a better alternative, maintain backwards compatibility. And if you break it, acknowledge what you're doing, forking your lib and leaving everyone who relied on you holding the bag.
Linux has maintained backwards compat for decades, there really isn't much excuse.
> Linux has maintained backwards compat for decades, there really isn't much excuse.
In what way? IIRC there is no stable ABI in Linux.
Regardless maintaining backward compatibility forever is non-trivial. Besides Java I can't think of another major platform still actively supporting their v1.0 work.
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.
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.
> 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.
Unfortunately what MS Office does that people often want is "present an interface with which I'm familiar" and "read all these MS Office files that people send me", neither of which LaTeX, CSV, and Python handle well (although I wouldn't be surprised if there were a Python module for at least rudimentary support of MS Office file formats).
Not to disagree with your main point—I also rely on that toolkit, though, as a not-very-computational mathematician, I find I don't have that much need for programming in my workflow—but I do think one has to be careful about what people are reluctant to give up.
I add a letter to distinguish between updates made on the same day: 2021-10-08a, 2021-10-08b. So far no one has been so quick with updates that I've gone past z, but I'll have my y2k moment someday.
> 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
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.
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.
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).
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
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).
If you accept this argument, the next logical step is figuring out what features are being used and how. Standard method is just guessing, but there's:
1. What rustc does with crater (linked from article), where you can actually test real code. On a smaller scale, the author of the article points out cryptography package for Python, which runs tests of its most popular upstream dependencies. This latter is probably feasible for many libraries.
2. Analytics, though this requires work to make it private and anonymous, and for libraries maybe requires system-level infrastructure. (Again, this was suggested by Alex.)
3. Beta testing, surveys, and other forms of user feedback.
I like his idea, but it sounds a little hypocritical coming from someone who advocated a change that broke many distros builds of the Python cryptography package.
Personally, I think he spent his "backwards-incompatibility budget" for about 5 years with that change because that's probably how long it will take for the new version of cryptography to be widely adopted and supported long-term.
I'd say that with a sufficient number of users, software development becomes pretty much politics; No matter how you change the status quo, some people will complain. You can't make everyone happy.
I'm still not sure if it's the best way to go about it though. But I think version numbering is still much stronger than tacking multiple "finals" to a file name. Happy to hear what others are doing!