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

https://alexgaynor.net/2021/oct/07/whats-in-a-version-number/

47 34 5 years ago

itamarst• 5 years ago

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.

ghoward• 5 years ago

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.

nammi• 5 years ago

I was really surprised Rich Hickey's talk wasn't linked to: https://youtu.be/oyLBGkS5ICk

yawnxyz• 5 years ago

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!

vegetablepotpie• 5 years ago

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.

intrepidhero2• 5 years ago

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

Yeah and, sadly, yeah. Someday.

xapata2• 5 years ago

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.

JadeNB• 5 years ago

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.

Zababa• 5 years ago

which can do everything MS office does

Not if "being usable by the people you work with" is a requirement, sadly.

intrepidhero2• 5 years ago

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.

jasonpeacock• 5 years ago

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)

BiteCode_dev• 5 years ago

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

zoomablemind• 5 years ago

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.

aimor• 5 years ago

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.

zz865• 5 years ago

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

dhosek2• 5 years ago

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).

mjevans• 5 years ago

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).

nighthawk454• 5 years ago

Conveniently, ISO8601 also sorts ascii-betically - so sorting in the file system sorts by date/time too

ignoramous• 5 years ago

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

agent327• 5 years ago

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.

psd1• 5 years ago

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

euske• 5 years ago

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.

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

Related Stories