Not to be overly facetious, but if SemVer is so great, then why do we hash the content of inputs at all? Just hash the `major` and `minor` components of the version number, since `patch` updates do not change observable behavior and/or spacebar heating is not a thing.
SemVer is partly social and partly technical. -- Socially, with semver you're promising that the software (especially its interface) won't change too much. Technically, if function signatures change, or if implementation behaviour significantly changes (in ways that'd break old code), you want semver to indicate that.
Nix's hashing of inputs solves a different problem. It wants to make sure you can have slightly different builds of packages available to the system.
> ...since `patch` updates do not change observable behavior...
Sure, the social guarantee of semver isn't enough to guarantee reproducible packages the same way Nix does, sure. But that doesn't mean that someone depending on v1.1.1 of a package would be happy to suddenly see v2.0.0, or that they'd be unhappy to see v1.1.2.
If skipping patch numbers I don't think this is actually SemVer. Rather it's a custom versioning whose major and minor convention is similar. (Which is fine just not SemVer.)
It's actually quite common to use the major version of semver for API versioning. Users of the API don't get to choose minor and patch versions though, they also don't need to because there's no breaking changes in them (ideally :) ).
Actually, semver would make sense if people used it correctly.
Changing the major means that it breaks backward compatibility. Changing the minor means that it has new features. Changing the patch means that it had bugfixes.
That's useful for libraries. Of course it's a bit less useful for executables. I just increase the major for executables, but if I need to backport a feature or a fix (to somebody who still uses an older version), then I use the minor/patch.
Just because one person doesn't find a piece of information useful doesn't mean that everyone else doesn't. Semver is a useful foundation to build versioning semantics upon, and nothing more. I find all three components to be useful for communicating the scope of changes in any given version, and tools like the OP that enforce these assumptions make semver even more useful. If you think that patch versions are useless, then you're free to omit them in your own libraries.
Why not actually adopt semver? It sounds like it’s hesitation to run up the major version number to quickly, but if your tool has breaking changes most releases then why not represent that in the version number?
Personally I'm frequently rug pulled by breaking changes in patch updates.
Imo, semver is just a way for lazy devs to break backwards compat and feel ok about it.
Which would be fine if they maintained their old versions, which of course they don't, so what's the point of semver? All the breaking change version change means to me is you've forked your library and left me holding the bag.
I either have to update my code to accommodate your changes or I need to change your code to accommodate security issues.
And fuck me sideways if I have you as a peer dependency.
Nearly every org I’ve worked in has used semver internally and nearly every time their version numbers were just incremented arbitrarily because there wasn’t an exposed API.
This lead to countless problems, not least of all because semver usually requires one to manually set the version number based on the change log and people are generally pretty bad at changing point releases.
So I’ve usually ended up changing the versioning scheme to build number (generated by the CI/CD tooling) plus some extra information like git hash and/or timestamp - depending on the application and whether that build information can be easily encoded as additional metadata or not.
The biggest problem I have with semver is that we don't have good enough tooling to reject minor or patch version bumps when major version bumps are actually warranted. I'm not sure it's possible to have that thorough of analysis in general.
Semver is handy for understanding what the maintainer meant to do. I guess in a lot of circumstances that's not nothing.
What I don't like about SemVer is that all breaking changes look exactly the same.
That's why I like to use SemVer with a small twist - a fourth number prepended to the regular three: A.B.C.D.
`B`, `C`, and `D` are the regular SemVer Major, Minor, and Patch. But `A` is "Generation" - something you increment only for fundamental changes to the codebase .i.e. 2.0.0.0 is a different generation of the product than 1.7.45.4, while 1.8.0.0 is the same generation, only with some incompatible APIs.
SemVer is working fine, you just need to face up to the real impact of a change on clients, not what you wish was the impact of the change. If a change breaks clients who rely on buggy behavior, you need to bump a version, not a patch number.
Using x.y.z version numbers does not imply semver.
I agree that semver as defined only really makes sense for libraries. When working on internal code, “breaking changes” are rarely a concern.
We instead use it to mean <major overhaul>.<feature change>.<minor bugfix>. That works well as semver-ish, and is more useful than just a date or a commit hash.
SemVer allows for near-arbitrary version suffixes which can convey info like date and hash, so nothing should stop you from using both versioning conventions together.
I feel like semver works great in the right context, for example if I'm building an API/Library which other deveopers are using, it helps them to know if there's been a major version bump, breaking change or just general patches.
However if it's just software for the end user, such as a web browser, it doesn't make as much sense, what is defined as a breaking change for someone browsing the web? And will they care? I've seen it be used for websites, ok great, but who's on the receiving end of these version change numbers?
At the moment everyone is trying to do semver even in situations when it's not needed.
reply