Pragmatic Semantic Versioning

When it comes to semantic versioning, the definition usually depends on who you ask. Everyone has their opinion on what constitutes a patch, what makes a minor, and what warrants a major version bump. In this article, I share my views. Keep in mind this is my opinion and it’s mostly constrained to the sort of software I release: open-source modules that are usually best served with a web browser. I made the clarification above because in other sorts of software, enterprise grade stuff, you might want to be more “strict” about releases. Think Node.js or io.js. For the majority of us, though, this is not the case. The consensual definition of semver more or less lies in the following bullet points. patch whenever you release bug fixes that don’t affect the public API in the slightest minor whenever you make a change that can potentially affect the public API, regardless of it being a bug fix or a new feature major whenever you make a change that breaks expectations in the public API, such as removing an API touchpoint, changing its inputs, or its outputs I prefer to take a pragmatic approach to versioning, as the above is usually a hassle. Bug fixes rarely break consumer code in practice, but almost always fall in the minor category. Consider a bug fix that someone else was using as a crutch and expected it to be a “feature”. That’s a minor because it breaks an expectation, even though it was a measly bug fix, and even though it wasn’t documented, and even though (chances are) nobody actually relied on it. My approach is to consider these bug fixes that may or may not affect functionality a patch, rather than a minor. This brings me to point number two in this thought.