> Can't seem to find any cohesive point in this piece.
Compressing complex, nuanced information into three integers is a fool's errand.
Compressing complex, nuanced information into three integers is a fool's errand.
The fool's errand would be expecting semver to encode all information about a version. That's not its purpose. Its purpose is to convey to users of a version some basic information about how it relates to previous versions from a user's perspective.
For more complex or nuanced information, the semver triad is not the place to look. Use git history, readme, changelog, release notes, etc.
It is tiresome to see people dismiss semver as bad because they misunderstand its purpose. "Semver is bad because it isn't what I think it should be" (then publish your own scheme), or "Semver is bad because it doesn't encode everything" (only the source itself could do that), or "Semver is bad because it would require some arbitrary numbers to increment faster than I am comfortable with" (i.e. "eww, semver has cooties").
Contrary to the article SemVer is okay to determine whether there is a compatibility break, as long as it is followed to the letter. Is is overly strict? Yes it is, but it does guarantee results. Maybe an argument should be that not all libraries should not follow SemVer because it is a burden similar to certifications and regulatory procedures.
This was a question a lot of people had to ask when npm didn't use package-lock.json and the `--save` option would automatically select a range of allowable versions.
Your coworker could `npm install` something entirely different than you and have all sorts of bugs because of it. And there are plenty of documented cases of exactly this happening.
The issue I see with semver is that it generally does not survive contact with the real world. People make mistakes when they package software, especially when they do it "without any warranty, express or implied". There's simply no substitute for testing whether a new package version will work or not; so in a realistic sense, semantic versioning simply doesn't work.
As a side effect, if you really try to follow SemVer it will force you to think ahead a bit more because the fact that you broke the API is reflected in something quite obvious, rather than buried in a change log somewhere.
I think it's important to realize that semver isn't about how accurately you summarize things. It's about what actions your customers will take from your version numbers.
If they're enterprise, then they'll expect to be able to apply anything short of a major version number change with an in-place software update, and they expect that they will not experience any significant or foreseeable breaking changes. It doesn't matter if you're using semver or not, this is how your enterprise customers will behave.
Part of the issue here, I think, is that you need to be roadmapping your project. If you're just churning and churning and producing features and changes all the time and you're not planning that, say, changes X and features Y go with v.Next, then, yeah, semver is going to be really hard. However, even if you're on the extreme end of agile you had to decide some set of features that made your product v1.0, didn't you? Why can't you do that again? You just have to decide how many features result in a major increment.
It does seem to lead you down the Java/Chrome versioning problem where the primary number just doesn't have meaning anymore (i.e., both Java and Chrome are technically still at v1.x, but they dropped that major version number because they realized they were never going to increment it).
Edit: I realize I'm describing semantic-ish versioning, but I'm of the firm belief that rules are meant to be flexible, rather than blindly followed. RFC 2119 is not a suicide pact, as it were.