Edit: -4. Touchy HN lately. You can diss Unix with toxicity but suggesting a clearly clickbait (hide the actual summarizing headline in favor of "you will be surprised by this big change") is a big no-no.
It wasn't immediately apparent to me that the new versioning scheme would be year.month/whatever, which is the real news, but it's less interesting.
"LibreOffice Changing To Year.Month Based Versioning Scheme" is far more clear than "LibreOffice 24.2 Will Succeed LibreOffice 7.6". The only reason I clicked through to the comments is because it was not immediately clear to me why LibreOffice would choose to skip to 24.2.
But the vast majority of the time, applications fall into neither of those categories.
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.
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.
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.
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.
https://semver.org/ contains the standard accepted definition
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.
Changes of that nature should come with a major version number increment. Or any large UI change, even if no new features are added.
I agree, but that isn’t semver. You seem to be defending semver without understanding what it actually is.
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
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.
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
In software for end users semver tells nothing most of the time.
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.
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).
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.
> 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.
If yes then I agree that it's a good guideline, but I don't think that's really "semver" at that point.