* * * * *
                                        
                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
[2] https://semver.org/
[3] https://www.hyrumslaw.com/
[4] https://github.com/spc476/mod_blog
[5] https://github.com/spc476/mod_blog
[6] https://nesbitt.io/2024/06/24/from-zerover-to-semver-a-comprehensive-list-of-versioning-schemes-in-open-source.html#floatver
---

Discussions about this page

The programmer's obsession with version numbers | Hacker News
  https://news.ycombinator.com/item?id=41376424

The programmer's obsession with version numbers - Lemmy: Bestiverse
  https://lemmy.bestiver.se/post/46571

The programmer's obsession with version numbers | Lobsters
  https://lobste.rs/s/bxmun3/programmer_s_obsession_with_version

Email author at sean@conman.org