The point of semver is that it's a kind of contract where you implicitly summarize the nature of the changes you introduce in a release in its version number. You provide contextual hints through the version number.
> Ok, but how do you know that a change (possibly a bugfix) in your code will break something (maybe a weird, broken thing) that I depend on?
That would be unintentional though. If that happens to you report it as a regression and most developers will give it super high priority and even release a hotfix to deal with it.
There's a big difference between accidental breakage, which is always a bug, and intentional breakage where it's reasonable to give some type of notice to people consuming your platform / API.
rumanator|5 years ago
This isn't rocket science.
Fix bug that doesn't change behavior nor the interface? Bump patch number.
Add feature/extend interface? Bump minor version.
Otherwise, bump major version.
That's pretty much it.
For a detailed definition:
https://semver.org/spec/v1.0.0.html
The point of semver is that it's a kind of contract where you implicitly summarize the nature of the changes you introduce in a release in its version number. You provide contextual hints through the version number.
jakelazaroff|5 years ago
How would you fix a bug without changing behavior? “Incorrect behavior” is the definition of a bug.
donmcronald|5 years ago
That would be unintentional though. If that happens to you report it as a regression and most developers will give it super high priority and even release a hotfix to deal with it.
There's a big difference between accidental breakage, which is always a bug, and intentional breakage where it's reasonable to give some type of notice to people consuming your platform / API.