> Here’s the problem: people interpret SemVer as permission to make breaking changes.
So, it isn't SemVer that is a mistake. It's the author's opinion that software should always be fully backwards-compatible, which would then require all SemVer-using software to be version 1.x.x (or 0.x.x, if we're zero-indexing.)
Or, alternatively, if SemVer didn't exist, this post would probably skip it altogether and just complain about people breaking backwards compatibility anyway.
> To say it another way: If you need to make a breaking change to your API, it means you screwed up. Don’t screw up.
If you make mistakes, please don't make mistakes instead. News at 11.
I agree. SemVer doesn't give you permission to make breaking changes -- it documents your decisions, assuming you're honest with SemVer.
This is very very useful. You can look at a library or dependency and weigh out if frequent, breaking changes are ok for you or not -- is the value worth the pain? Alternatively, if the major version never changes, you can have more confidence that you won't have to rework your code on every library update.
So, it isn't SemVer that is a mistake. It's the author's opinion that software should always be fully backwards-compatible, which would then require all SemVer-using software to be version 1.x.x (or 0.x.x, if we're zero-indexing.)
Or, alternatively, if SemVer didn't exist, this post would probably skip it altogether and just complain about people breaking backwards compatibility anyway.
> To say it another way: If you need to make a breaking change to your API, it means you screwed up. Don’t screw up.
If you make mistakes, please don't make mistakes instead. News at 11.