>SemVer is a social construct, not a contract. It's nice when it applies, but you cannot rely on other developers to adhere to it.
Whats the solution here? Fuck standards? Imagine if we had that same attitude with regards to HTTP.
Whats the solution here? Fuck standards? Imagine if we had that same attitude with regards to HTTP.
I've never found standards to be all that standard.
I think the right solution here is to build version numbers off of your black box tests.
The devil is in the details though. What’s a change to the tests mean exactly? Adding new tests is probably a patch release. Modifying tests demands at least a minor version number, but what makes it a major version number? Deleting tests probably qualifies. Removing assertions probably does too.
But now what if the author is bad at tests too? Can I substitute my own? (I could do that right now for regression testing, and in fact I do occasionally for interdepartmental issues).
Well, many do. You wouldn't believe the number of broken HTTP clients/servers out there.
The difference is that most HTTP clients/servers have to work with some significant subset of the pre-existing HTTP infrastructure (otherwise why would anyone use them?) and so that constrains their implementation to be "mostly correct". It's literally network effects :).
Libraries on the other hand usually start out with a single consumer and have no such constraints on their implementation so you end up with various levels of ossified brokenness or breaking non-ossification.
In any case you need to read through the changelog or (absent that) the actual code diff and think about how you use the application. It's not 100%, but no versioning system will be able to identify how you use code and how you expect the semantics of an application to be.
Ideally, there would be a tool that can inspect your entire codebase and determine if the change is "breaking". This still has issues if the change lies outside of your codebase (perhaps such as changing the configuration of your AWS services).
Or use ComVer
And I just described 80% of the node module ecosystem...
But one if the main semver violations I see in the wild is a project slotting major changes into the minor version number because they want to avoid high major version numbers for some reason or have some romantic idea of what a major version bump “should be”.