[eridius]

> What if it's a dll, .so? You upgrade and find out that your program is broken.

If it's not backwards-compatible then it needs to bump the appropriate version number (in my proposal, that would be the second dotted component). So I'm not sure what you're trying to say here.

> * Sometimes the API stays the same but the code behind the API changes a result (for example, secure_hash goes from MD5 to bcrypt)?*

If it's a non-backwards-compatible behavioral change then maybe you need to design your API better such that this kind of change is expressed in the API. After all, if you expect anybody to ever upgrade to your new bcrypt version, you need to provide some path for people to still work with their older MD5 hashes anyway.

> What about non-type safe languages (like HTML or JS, so things like Firefox or Chrome)?

Not something I particularly care about. Though it doesn't really matter anyway; even if you think the breaking change number is too "subtle", anyone who's manually upgrading to a new version instead of letting their package manager do it should already be prepared to deal with breaking changes, because if there aren't breaking changes then their package manager should have been happy to upgrade without any manual intervention.

> The point is that you should avoid breaking other people's code if you can. What happened if that removal of one function in that one module costs me a full years of work?

I have no idea what point you're trying to make here. My suggestion was just about changing the format of the version number, and has no bearing whatsoever on the actual breaking changes you do or don't introduce. I'm certainly not advocating for removing functionality.

[cookiecaper]

I think, and correct me if I'm wrong, but I think he's saying that semver's system that forces major version bumps for breaking changes is good because it discourages the maintainer from making breaking changes more frequently than he is comfortable releasing a new major version. That is, the effect of getting a maintainer to batch up breaking changes in exchange for version consistency is positive, and thus semver should not be changed as you propose, because it would decrease the cost of releasing a breaking change.

[eridius]

There's still a cost associated to releasing a breaking change, which is users have to manually upgrade, their package manager won't silently upgrade for them. So if I release a breaking change, I know any bugfixes included in it or later builds will take a while before they end up in the hands of users, because most people tend to put off dealing with breaking changes until they have time to actually investigate the changes.

But with my proposal, users can see that the breaking change is a "minor" one, and therefore they don't need to be prepared to learn about a bunch of big changes in order to upgrade.