A look at Whim’s changelog shows the somewhat unusual date-based version numbering scheme I use with it. The most recent release, for example, has the version number 1.2020.07.19.1.

In truth, it’s only the latest such scheme of mine. Short of patience with traditional version numbers, which have never really seemed to fit my own projects, I’ve experimented with date-based styles over the last year or two.

I didn’t invent the idea — in fact, I began these experiments after a resident of a Perl IRC channel, seeing my frustration with version numbers, suggested the route to me. But no “standard” exists for date-based versioning, as far as I can tell, so I needed to get creative anyway. With Whim’s version-number style, I believe I’ve hit on one that I really like, and could see myself using with other projects.

The dot-separated numbers of this scheme break down this way:

• The first digit shows the software’s major version number, in the traditional sense. For any project, I’d expect it to change rarely, if ever. Should e.g. Whim ever feel like it really has grown into a “Version 2” — a true sea-change — then I will increment this. I otherwise pay it no mind.

• The middle three numbers denote the year (four digits), month (two digits), and date (two digits) of this release. I manually update these as part of the release process.

• The last digit represents a “date-disambiguator”, allowing for multiple releases of a project within a single day — useful for quick patches of fresh, discovered-upon-delivery bugs. The first release of any date gets 0 here, and the next one gets 1, and then (if things really boil over) 2, and so on.

So, a Whim release stamped 1.2020.07.19.1 tells me that it is a revision of Version 1 released on July 19, 2020, and was the second release of that day.

And that’s all I want to know from the number! Knowing the when of a release provides far more meaning to me than, say, looking at Plerd’s current version of 1.821 and trying to extract any at-a-glance sense at all from it — other than annoyance to see it running out of decimal headroom before hitting 2.000, despite my having no plans to actually cross that line.

Making four of the five numbers purely objective (and the fifth one almost completely static) also relieves me of burning any brain power on how to bump the version number this time. Hmm, if the number is 1.821 now, and I fixed a couple of gnarly bugs and made a few other tweaks, should I increment to… 1.822? 1.830?? 1.821.001??? Going fully date-based discards this irritating question tidily.

Maybe if I worked in a large team on a rigidly organized project that pinned its version numbers onto a roadmap with meaning and ceremony, I would feel happier with a traditional numbering scheme. But with my little open-source follies, I’m much more comfortable with an easy-to-read date-based scheme that still allows for the ever-increasing digits that package managers require.

This article was also posted to the “code” section of Indieweb.xyz.