I don't trust saving a file that hasn't changed without checking if things compile/pass tests.

> If you answered "no", then you are basically admitting that Semver is worthless in practice

I hugely disagree. Version numbers give me a good idea about what level of changes to expect. Upgrading from 1 to 2 implies a larger review is needed, I'd not just check compile/tests. Upgrading from 1.4.656 to 1.4.657 and I don't expect to have to check the docs for major changes to how things work.

Dates, pure increments etc don't have this. Two releases a day apart can be wildly different - a patch release fixing a logging format and a fundamental API change.

It's a method of communication . Not being perfect doesn't make it useless.

What would you do for upgrading from 1.4 to 1.5?

> Dates, pure increments etc don't have this.

Right, but most versioning schemes are not pure increments and nor pure dates exactly for that reason. You don't plan to release twice a day when your version scheme is year-based; the second number is frequently used for when it's inevitable, making it a hybrid scheme. Still not compatible with the semantic versioning.

Semantic versioning also effectively shadowed a previously widespread decimal-based versioning (e.g. 1.00 < 1.09 < 1.5 < 1.99 < 2.0). There are pros and cons for both formats, but decimal-based versioning makes authors to pick a suitable increment for communicating changes, and forbids them to perpetually delay the major version (which can be a pro or a con, I personally think it's a pro).

If semantic versioning simply wanted to codify and mechanize the best practice, it should have instead adopted Debian's [1] which tried a lot to unify existing conventions.

[1] https://www.debian.org/doc/debian-policy/ch-controlfields.ht...

Something in between? More checking and a glance over the changelog at least to check for added things I should use. Depends how important the component is and risk to the business.

> Right, but most versioning schemes are not pure increments and nor pure dates exactly for that reason. You don't plan to release twice a day when your version scheme is year-based; the second number is frequently used for when it's inevitable, making it a hybrid scheme. Still not compatible with the semantic versioning.

Sure, those were the suggested options I was countering. Dates of any form don't tell you much about what's practically changed though.

> and forbids them to perpetually delay the major version (which can be a pro or a con, I personally think it's a pro).

"Version 2 because it's been a while even though this is a logging change" sounds awful to me, as does "welp we've used our 99 releases so now it's a new big number" or "oh shit we used 1.1 so now we only have 10 releases possible". You don't need to make major revisions.

> There are pros and cons for both formats, but decimal-based versioning makes authors to pick a suitable increment for communicating changes,

Isn't that largely what semver does? There are three major buckets.

Still. My point is that it's not worthless, not that it is objectively better in what is a very subjective area (communication).

That's not how people used to do decimal-based versioning. They instead tend to be more conscious about the relative amount of changes and how to quantify them. Some changes are worth 0.01. Others are worth 0.1 or 0.05. If many changes are expected before the actual major version, either increments are lowered (say, 0.001 instead of 0.01) or many changes are batched into a single release of the reasonable size.

> There are three major buckets.

That's too many, I believe---see my other comment. There is a good reason to have at least two components, and authors and/or users may want much finer increments (4 or 5 would be the practical maximum though), but three components as defined by the semver don't seem to be justifiable. I'm not against other existing schemes using three numbers.

You can still do that with semver if you want to try and encode more information and hope that people read your docs to understand what specifically you mean by the size of the changes.

> If many changes are expected before the actual major version, either increments are lowered (say, 0.001 instead of 0.01)

Planning an entire major version and how many releases you have coming up sounds rough. Why not give yourself more room? Make it two numbers not a decimal. You could then add .0 to everything.

> or many changes are batched into a single release of the reasonable size.

I'm not a fan of delaying releasing fixes just because changing a number is hard. But you can still do that! Just increment minor or major and set patch to 0. This also buys you the ability to patch an older minor release!

I kind of get the argument against minor and patch, but think they are usefully different. I can't imagine 5 different parts.

Having a reasonable standard means not having to know the preferences of 100 maintainers.

Is it perfect for everyone? No. Is it fine? Sure. My originally point is that not being perfect doesn't mean it's useless.

“Completely arbitrary, utterly inconsistent (across vendors, across products from the same vendor, and even within the same product over time) and often marketing driven” is how people used to do decimal versioning, and any claim to the contrary is romanticizing a very messy past.

The grandparent's description is a perfectly reasonable example of what would actually happen.

I'd read the release notes, and spend a little bit of time thinking about if they impact my project.

For a 1.4.1 to 1.4.2 bump, if my (comprehensive) tests pass, I'll land the upgrade.

Outside of new things it informs you about the work expected with downgrades. Going down in minor versions and you should check for breaking changes or removed functionality.

Such change is not distinguishable from a patch release because, according to the semantic versioning, both should be trivial to upgrade. In the other words, if the semantic versioning did work as intended, upgrading from 1.2.3 to 1.2.99 and to 1.42.0 should be same to users. If it's not the case, there should have been some breaking change. And clearly this is not how users feel about the minor version increment.

> Outside of new things it informs you about the work expected with downgrades. Going down in minor versions and you should check for breaking changes or removed functionality.

If you need downgrades the distinction among major, minor and patch versions does not matter because either:

1. The library author has broken the premise of semantic versioning, or

2. You have entirely separate requirements that are not part of the public API (whatever it is) and thus the library author didn't honor them.

They're absolutely distinguishable, they convey a different scale of change. Just because you should be able to blindly upgrade doesn't stop that. If nothing else, it indicates there may be deprecations. You don't want to wait until things break before dealing with those.

> If you need downgrades the distinction among major, minor and patch versions does not matter because either

You've never had to downgrade a package for other reasons like matching a version used elsewhere? Compared versions of a tool with another developer whole debugging? Downgraded due to an introduced bug? None of those break semver.

Again this is about communicating.

Minor vs. patch releases are absolutely distinguishable because authors did say so, but changes are not---unless you actually try to use new features.

> If nothing else, it indicates there may be deprecations. You don't want to wait until things break before dealing with those.

Deprecations are not breaking changes, so it shouldn't matter anyway. The semver rule of requiring the minor version for deprecations is pretty silly. I do see the intention---give enough time before the actual removal---but the rule is too strong and smells of retrofitting.

Semver's unclear distinction between minor vs. patch versions is also visible from the coexistence of "caret" requirements and "tilde" requirements in many semver-enabled systems. The former can upgrade to any minor versions, while the latter won't if the required version is specified in the full three-part form. Which one should I use? Depends on packages? Is that any different from having a different versioning scheme per package?

> You've never had to downgrade a package for other reasons like matching a version used elsewhere? Compared versions of a tool with another developer whole debugging? Downgraded due to an introduced bug? None of those break semver.

I do a lot of downgrading, but I don't trust semver and at least test them again (and look at actual changes if I can). Bugs do not break semver, but at that point the very reason to trust semver also disappears.

Also, consider the case where x.y.0 has introduced a new feature I need and also a new shiny bug. Obviously I can't no longer downgrade and semver offers no other solution. The common way to deal with this is to fork and vendor local changes (I did encounter this situation as recent as 2 months ago). I should note that semver in principle should have prevented this for other x.y.z versions (z > 0), but bugs introduced by x.y.z are much rarer than x.y.0 because x.y.z are supposed to be bugfix-only releases anyway.

Minor = Adds new API calls.

Patch = Changes the internal behavior, but not the API.

SemVer's distinctions are essentially useless for applications (and particularly so for GUI applications), but do make some sense for libraries.

SemVer is one-way. Downgrading usually still needs the same care as a major version change.

SemVer is mostly intended to limit what the version number conveys. It doesn't add extra info (like, is this a bugfix?) but instead takes that away and forces it into the release notes.

Dynamically-typed languages make this harder, because internal behavior and the resulting type signature are less separate than with a statically typed language where an accidental type signature change (e.g. returning the wrong type) will break at build time.

I'm not understanding, sorry. There are changes that fit in minor that don't in patch - they're not equivalent. I think we have crossed wires somewhere on this point.

> Semver's unclear distinction between minor vs. patch versions is also visible from the coexistence of "caret" requirements and "tilde" requirements in many semver-enabled systems. The former can upgrade to any minor versions, while the latter won't if the required version is specified in the full three-part form. Which one should I use? Depends on packages? Is that any different from having a different versioning scheme per package?

Tilde is "this patch and above don't go to a new minor version". Caret is the same but allows minor upgrades.

Which you use depends on your project and testing, and yeah you can base it on what the maintainer is like. Some projects break all the time and you don't want even patch releases. I'm not really sure why they added those tbh I'd prefer just ranges. They're just shorthand for ranges anyway.

Again, it's about communication. Some people being bad at communicating or maintaining software doesn't make communication pointless.

It brings the problem down to one versioning scheme, which you can rely on to different degrees. The overrides are then significantly more contained than having scores of various different things with formats that require different parsing despite looking identical. You instead have one thing and if you're unlucky you have a misbehaving package in your dependencies.

> Deprecations are not breaking changes, so it shouldn't matter anyway.

Yes, which is why it isn't a major change. This is all about the maintainer communicating with you that this is more than a patch

> Also, consider the case where x.y.0 has introduced a new feature I need and also a new shiny bug. Obviously I can't no longer downgrade and semver offers no other solution.

Semver doesn't fix bugs no, but I don't understand the problem you're describing. That would be followed by a patch release with the same minor versions number right?

How does semver make any claims to prevent bugs being introduced?

If it's a local change you make would you have a distinct package? If you want to have the same package name just make a patch number yourself and mark it pre-release. That's literally what it is right - a patch that's not yet released.

If I seem to attack a weird strawman, you are not very wrong. Semver is useless but doesn't hurt much either. Semver can somehow encode one-part and two-part versions as well by appending excess zeros. I'm much more concerned that embracing semver (or really any other alternative versioning scheme) makes us overlook the actual problem---versions may detect but can't fix breaking changes. A vast majority of breaking changes is mechanically fixable, and we all know how it is beneficial. We should embrace a method to reduce perceived breaking changes, not a method to point out possible breaking changes.

These seem like entirely distinct goals that should be pursued separately. Yes, from the perspective of a library consumer, any breaking change is a problem. But from the perspective of a library author, there's a crucial distinction between breaking changes that I intended to make and breaking changes that I didn't intend to make. The tool in the OP is for use by library authors, with the goal of eliminating unintentional breaking changes, and thereby reducing the number of breaking changes that my users are forced to endure. And what you're asking for is a tool to be used by library consumers, in order to mitigate intentional breaking changes. Both these tools can exist, and both benefit (at least marginally) from semver. Semver isn't a panacea, it's just the simplest possible foundation to communicate ideas about versioning. It's entirely welcome to invent concepts beyond semver to perform even more advanced communication.

Surely you understand that not all projects use semver. When projects that do not use semver have version numbers that communicate nothing, that's not a failure of semver. Indeed, you have accurately derived the reason why semver exists: because it would be useful for version numbers to have known semantics. The above comment is, seemingly by accident, an argument in favor of semver.

Fair point, but then wouldn't it have made more sense to also define a unique syntax for semver? If I can't tell whether a project follows that standard by looking at the version number I still can't rely on it without looking it up.

That doesn't mean it's useless, but it's an unnecessary source of confusion. With Rust crates there's also the problem that developers cannot use a different syntax to indicate they don't follow semver - cargo will refuse to compile the project. While it would be nice if all packages followed a standard this will realistically never be the case and enforcing the notation won't change that.

SemVer only makes sense for projects whose principal function is presenting what is consumed as a single, unified API, because the first two components of SemVer are actually a version number for the presented API, and the last component communicates the sequential version number without API changes.

Blender was not semver until 3.0 so that is perfectly valid. You can't complain about semver projects and inconsistent versioning and then pull out non-semver projects.

That said, I maintain close to a dozen Rust utilities, some of which only get updated every two or three years. And when I update them, I try to update all their dependencies. We're talking 250-400 transitive dependencies in most cases, and typically two years of evolution of all of them. In other words, this is a worst-case scenario for semver. I'm often looking at 600 "library-years" of supposedly compatible changes.

4 times out of 5, the "semver-compatible" updates work flawlessly. The 5th time, I'll occasionally run into a minor problem that takes me 20 minutes to clean up. Once every several years, I'll run into a genuine headache.

To me, this is stunningly successful. Rust semver isn't perfect, but it's a genuine joy from a maintenance perspective. And I expect things to get even better, thanks to tools like the one in the OP.

Thirded. Tests get run before I commit, period. The grandparent's apparent argument that semver has failed because you have to run tests when upgrading patch versions is utterly alien to me. Has any semver proponent ever claimed such a thing?

I run the tests after running even a part of a file through the formatter. And no, I don't work in Python.

In practice, a dependency I should not trust to have done diligence in semver management is only a couple steps past a dependency I should not trust to run on my machine. Ignore any dependency with less than 50k downloads and 'what if other people are dumb' concerns like this one just melt away.

The issue in Rust isn't that semver isn't doing the right thing for us. It's that every so often (maybe as rarely as 2-3 times per year for the entire Rust community!) there's a spectacularly painful and regrettable accidental semver break that causes tons of effort to be spent by both maintainers and many downstream users.

For every such incident, there are probably thousands of little semver violations here and there that we don't notice and where nobody is affected by them.

cargo-semver-checks is about letting maintainers have actionable information at the right time so they can engage in well-informed decision-making. Without this tool, the alternative is: every time you publish a new version, roll a d100; on a roll of 2 or 3, you broke semver but nobody noticed; on a roll of 1, you wake up to a GitHub issue with 1000 other issues linked to it that says "you broke semver, please fix ASAP." This is the part that sucks! (The numbers are approximately accurate based on our study of the top 1000 most-downloaded crates.) The remaining 97 times, everything is great -- you publish a new version, everyone happily uses it, astounding success all around.

I'm glad to hear of your positive experience with semver. Unfortunately, the issue with semver violations is that their impact has extremely high variance, easily ranging between "nobody noticed" and "ecosystem-wide pain":

- Most of the semver violations we found appear to have never been reported or noticed. After talking to a representative subset of the maintainers of those crates, they were generally surprised to find out a semver violation had happened.

- At the same time, a quick search for "violated semver" in Rust repos on GitHub will surface hundreds of issues, many of them heavily linked-to by issues in other projects. Every such issue represents dozens or hundreds of cumulative engineer-hours of triage and remediation in both the project where the semver accident happened and in affected downstream projects. All this work is regrettable, in the sense that both maintainers and downstream consumers would have preferred if it could have been avoided.

Most semver violations aren't intentional -- they are accidents that happen to all of us regardless of skill level, carefulness, experience, etc. Most of the time, those accidents go unnoticed or have minimal impact. Every so often, they trigger nearly ecosystem-wide consequences for a few days or weeks. (Some examples on my blog: https://predr.ag/blog/toward-fearless-cargo-update/ and https://predr.ag/tags/semver ) And sometimes, breaking semver on purpose can be the correct thing to do!

cargo-semver-checks aims to be a tool such that maintainers never have to say "if I had known this API change had happened, I wouldn't have published this version." Its biggest impact should be at minimizing or altogether preventing those ecosystem-wide semver issues that happen from time to time. Our day-to-day experience with semver should remain unchanged otherwise.

You can think of cargo-semver-checks as an automated way to answer a series of queries like "are there any public functions that existed in the previous version and don't exist in the new version?" Any results produced by any of those queries are examples of breaking changes.

This is why our "more than 1 in 6" study found so many previously-unreported semver violations — in our study we were able to find issues in all sorts of dark corners of library APIs, then generate programs specifically designed to rely on the affected behavior in a way that works fine in one API version and causes a compilation error in the subsequent (non-major) version.

that's exactly my point, without this great tool he can't know whether semver is broken from his practical use since his use is not exhaustive

> If you answered "no", then you are basically admitting that Semver is worthless in practice.

Because everything that is not perfect is worthless indeed… Some people should really learn about nuance.

As a concept it's relevant any time you have a protocol or a communications channel between agents that aren't rigidly kept in sync. Think network protocols, on disk formats...

The alternative to semvar in the filesystem world has historically been feature bits, but feature bits suck because there was an order in which you rolled out features and feature bits do not preserve that ordering.

Meaning users can (and will, because users do crazy things) end up in a state where they have all the modern feature bits enabled but not the one from 5 years ago and you never tested that configuration.

Learn semvar. Use semvar. Semvar good.

If you're seeing 1.2.3 -> 2.2.3, updates, i..e the dev is saying THIS 100% BREAKS SOMETHING IN MY OPINION, and you just do your normal set of analysis and walk away happy that's a bit scary.

If you do anything other than your normal analysis, you've just gone ahead and used semver.

I'm going to take a wild guess that you're going off of experience from something like npm library versions. That ecosystem is a mess, and I don't blame you for mistrusting it.

On the other hand, the Go language has maintained the Go Compatibility Promise remarkably well. https://go.dev/doc/go1compat

In other words, whether or no semver is useful depends on how well its followed. The versioning compatibility would be a problem regardless of the version number system followed. Case in point: Windows 95 v Windows 10.

You are perhaps right when you say that semver had failed, but what you list above as alternatives are less expressive. Semver admits a tree of versions (weak ordering) but your alternatives are strictly ordered.