The programmer's obsession with version numbers
It's yet another round of hand wringing about software versioning [1]. Woot!
Over the years, I've found that semantic versioning [2] works for me, but only for code code that is to be used in larger projects, like libraries, modules, or classes. Yes, a code base using semantic versioning doesn't always mean the code base follows semantic versioning to the degree that some would like (like any bug fix should automatically update the major version number, because bug fixes could break some code, somewhere [3]). But in my mind, it signals intent, which, sans an extremely obnoxious and overly bureaucratic process, is the best we can expect.
So for me, the MAJOR.MINOR.PATCH of semantic versioning breaks down like this:
MAJOR
Some change in the code base was made; either a change in API (Application Programming Interface) behavior, removal of some portion of the API, file format, or otherwise any visible change (except for bug fixes) in how the code works. Work will probably be required to update to this version of the library/module/class.
MINOR
Only additions to the API were made, in a backward compatible way. No work is expected, unless you were already using a name used in the updated library.
PATCH
A bug fix. The intent is for no work required to upgrade, unless you were relying upon the buggy behavior, or used a workaround that might now interfere with the library.
For applications, I've found that semantic versioning doesn't work. At least, it doesn't work for me. I've switched to either using a monotonically increasing number (mod_blog [4] is now at version 60—but given the five releases in just the past week because of a misplaced obsession with version numbers, I might entirely stop with the version numbers—especially since I seem to be the only one using it) or skip it entirely (my Gemini server [5] has no version number, but it's had 322 commits over its five year life so far).
The worst form of versioning [6] I've enountered is “named versions.” A “named version” give no semantic information about the version and, at least to me, leads to confustion. Is “Bulldog” newer than ”Beagle?” Or is “Bloodhound” the latest version? Oh, it's “Berzoi” that's less than 20 minutes old. Sheesh.
But if I had to apply “semantic versioning” to an application, I would like information about any breaking changes to either work flow or file formats. To me, an incompatable change to a file format, or any change in workflow (even a change in location of a menu item) is a breaking change (muscle memory is an incredible drug). Hell, even a change in color scheme is enough to possibly break my workflow (I'm looking at you, Google Maps, who changed the color of all the roads to the same color! Why? I liked the distinction between highways, major roads and minor roads. Did you see a 0.001% increase in engagement for that change? Did someone get promoted just because of that change? Okay, I'll stop ranting now).
[1] https://lobste.rs/s/ukriql/you_re_not_mature_enough_release_your
[3] https://www.hyrumslaw.com/
[4] https://github.com/spc476/mod_blog
[5] https://github.com/spc476/mod_blog
Discussions about this entry
The programmer's obsession with version numbers | Hacker News
The programmer's obsession with version numbers - Lemmy: Bestiverse
Source