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
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