PSA: when you use #semver (Semantic Versioning) for your project, please stick to the rules. Breaking (API) changes require a major version bump. Please don’t break the API between 1.4.x and 1.5.x. Because that’s unexpected behaviour and really bad for users of your project. #kthxbaihttps://semver.org/
@jwildeboer PSA: Stop using semantic versioning for software artifacts which are not a library with a public API surface. There is no point in doing semver for your run-of-the-mill webapp.
@jwildeboer When there is no API, how do you decide whether to bump the major version number? What is a backwards-compatible bugfix? calver.org is a simpler alternative for that.
@jwildeboer Well, semver in general falls down very quickly when you try to fix a bug, which affects part of the API a small minority or maybe even nobody uses. Now you need to bump the major version, which means nobody can update to it, because you need to update all dependencies first to allow the newer version.
Alternatively, what breaks my applications the most usually, is minor behaviour changes, that don't change the API and look good at first, but completely break some specific users. So distros update the dependency and suddenly one application is completely broken.
Not that I have any solution to it, but semver makes things look so simple, that are very complicated to put into practice. What exactly defines the API is very hard to accurately describe. Source compatibility and binary compatibility can be defined, but an API basically covers every behaviour or only documented behaviour and in practice that is quite hard to pin down and have users come to the same conclusion.
Add comment