I don't think semver is very useful for applications as opposed to libraries.
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.
Makes sense to (some) developers, but to an end-user semver is rather nonsensical. Everyone can understand calendar-based versioning.
> Everyone can understand calendar-based versioning.
Yes because it does not any meaning. Earlier major versions were reserved for adding new features, but since CADT took over the world, they just mean another version which has nothing to do with the old one.
If the year is 2023 and I am running WhateverApp 2010, I instantly know I am running a 13 year old version, and it is probably a good idea to see if there is a newer one-even if I’m completely happy with the 2010 version. Decent chance of new features, some of which I might find valuable; also, with every passing year, the risk of interoperability/compatibility problems (with file formats, new OS versions or versions of other applications)-even if I haven’t hit any of those problems yet
Whereas, if the year is 2023 and I’m running WhateverApp 2021, that’s only a two year-old version, so absent any specific problem or missing desired feature, looking for a newer version is going to be a lower priority
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.
SemVer is more useful in Apps if you use feeling vs strict rules. A massive UI overhaul (but without breaking features) is almost definitely a major version bump but SemVer says it's a significant minor jump (5.0->5.5), at best.
The problem is that SemVer was released for libraries, where it's rationale and rules make sense. But the abstract spirit of major.minor.patch makes more sense at an application level.
If apps followed SemVer properly they should be bumping the major version for most UI changes (let alone overhauls), as they all break user workflows. If a button moves, you need to learn the new location. Shortcut changes? Tough luck, your muscle memory just deleted the last hour's progress.
I don't think that's useful for users though. It's best to assume that any upgrade will break something for you, so maybe optimize for new features and bug fixes (if you even need any). Which is where other version schemes can be more helpful as they can give a greater scope of the number of changes (e.g CalVer tells you how out to date you are).
> If apps followed SemVer properly they should be bumping the major version for most UI changes (let alone overhauls), as they all break user workflows.
This is just reiterating my entire point. People follow the rule/strict interpretation of the law and SemVer breaks, you should be following the spirit of the law.
I didn't exactly intend to disagree with you, but I did get a bit combative there though, as I narrowed in a bit much when writing my response. I wanted to expand (and work out my thoughts) on
> A massive UI overhaul (but without breaking features) is almost definitely a major version bump
as I think effect of UI changes tends to be underestimated. Just because v1 & v2 both have a button to frobnicate doesn't mean that they are equal. If v1 had a big large frobnicator in the main screen, and v2 buried it in a menu, you could say that no feature was broken, but the user interaction is very different.
That sort of change often gets rolled into a minor/patch bump, but it does break workflows. However if every change like that bumped the major version, it would be noise. There would be no way to judge the scale of the changes from v9 to v23 vs v14 to v16.
I'm not sure if the spirit of the law of SemVer applies here though. The type of change is not important, only how much has changed. Bugs can be features.
Calendar versioning makes way more sense for end user applications, especially those with GUIs. There isn't much concept of a non-backwards breaking change in something like libreoffice, so semver ends up trying to expose information that isn't there.
Semantic versions only make sense if you anticipate discontinuous breaking changes in the future, with periods of stability between. If no new version will be a breaking change, or if every new version will be breaking, it loses meaning and you might as well go date-based. (Or, if you're Linus Torvalds, completely arbitrary.)
Part of my point is, if the software doesn't have a concept of "breaking change" semantic versioning makes no sense, so you might as well just use numbers that change with every release so you can easily refer to when bugs got fixed or, maybe, features got added.
Applications do have the equivalent of breaking change, though. Sometimes literally in the sense that file formats change, but more usually in the sense of having to relearn how to do things, or the removal of features.
lol. "Breaking change: all English text is rendered right to left now. In can be changed to bottom to top in the compile options. Left to right has been removed."
