Calendar-based versioning gives a good sense of how old a version is. As an end user of LibreOffice this does a better job of helping me stay up to date, and tells me a lot more than semver - what is even the “public API” of a GUI app?
Semver in applications tells you important things such as how different a release is and how much incompatibility to expect. "Public API" doesn't really enter into it, but it's certainly useful to know at a glance how different the release is from the prior release.
Calendar-based versioning gives you no hint of any of that. It's important to know because if it's a minor release, I'll want upgrade to it right away. If it's a
bugfix release, I'll want to upgrade urgently. If there are major changes, I'll want to put it off until I have time to handle the disruption. If I have to look up how large the changes are, I'll just assume every release represents a major change and will put off upgrading until I have time to deal with it.
True, semver doesn't literally tell you how old a release is, but how often is that important? What you really want to know is whether a release is newer than the one you have, and semver does tell you that.
> Semver in applications tells you important things such as how different a release is and how much incompatibility to expect
I disagree that it tells you either.
Release A adds massive new features, with hundreds of thousands of lines of new code, dozens of new third-party dependencies, but with zero (intentional) backward incompatibilities – increment minor version only.
Release B only removes one tiny obscure legacy feature which almost nobody used. But that's backward incompatible, so must increment the major version.
For any user considering whether to upgrade, release A is almost surely a much bigger risk than release B – yet semver tells them that B is major whereas A is only minor.
Similarly, consider release C which removes dozens of features, many of which are widely used. Obviously release C is a much bigger risk than release B which only removes a single obscure legacy feature – but since semver treats backward compatibility as a binary "yes-no", it fails to communicate that release C is a much bigger deal than release B.
> True, semver doesn't literally tell you how old a release is, but how often is that important?
Well, if the year is 2023, and I'm running WhateverApp 2010, I instantly know I'm running a really old version, and ought to look into whether there is a newer one. Whereas, if I'm running WhateverApp 2021, it is only two years old, so I'll put researching newer versions a lot further down my priority list.
As far as I'm concerned, replacing a feature with a similar one (major version bump in semver) and adding a new feature (minor version bump in semver) are pretty much completely equivalent to me. Adding a new button for a purely-new feature is a "breaking change" - that is, if it's in some keyboard-navigable menu, I now lose muscle memory on how many 'down' presses it takes to reach it (or, in a GUI, the entire layout might have changed to fit the new button), which is about as annoying as being forced to use a new workflow due to a replaced/removed feature (assuming I ever used it).
So semver for GUIs is just entirely useless to me. Whereas a calendar-date actually gives useful information:
- if I desire some obviously-desirable feature, how likely is it that the newest version might have it (semver even de-emphasizes this via making additions minor bumps!)
- whether it's worth bothering to report a bug (devs likely won't care about problems in years-old versions, but 10 semver major bumps could be anywhere between decades and weeks old, depending on how the developers chose to define "breaking change")
- whether the version is representative of the up-to-date state (for semver you could maybe determine this if you looked up the up-to-date version number (already a big ask) and subtracted, but again that'll primarily only tell you about amount of removed stuff (and not even amount!! just the number of batches! you could have 10 major bumps have less removed stuff in total that one major bump), not added stuff)
- whether whatever package manager gave me a reasonably-up-to-date version
You're not describing semver, you're describing traditional feature-based versioning, which I agree is nice.
This is semver:
> Remove some obscure feature which almost nobody ever used? Backward incompatible change, must increment major version.
> Add some major new feature which is a massive quantity of code, visible and likely important to all users–but 100% backward compatible? Increment minor version instead.
There are many, many modules that make up LibreOffice. At what point do you think they should update the major version?
It doesn't work for an app like LibreOffice. For a library with well defined interfaces, it does make sense as you can easily find breaking changes. LibreOffice shouldn't be making these sort of breaking changes. The libraries that under LO are using proper semversioning.
As a personal user of calender versioning, it solves some of my problems with sematic versioning, telling when it was released at a glance, and it makes it easier to apply; just look at the date, making it 0-1 clicks. Sematic versioning, on the other hand requires you to remember the last version, and apply accordingly, which takes 1-3 clicks for me.
To end users who only care that they have the latest version, both schemes serve the purpose equally well, so why not go with semver?
But I'll take even calendar-based over code names. Code names tell you literally nothing.