Semantic Versioning is a terrible mistake
-
The Reinvigorated Programmer[^]:
When I first heard about Semantic Versioning, or SemVer, I thought it was one of those ideas that’s so obviously right that we were all going to benefit from someone having just codified it and written it down.
So it's a breaking change?
-
The Reinvigorated Programmer[^]:
When I first heard about Semantic Versioning, or SemVer, I thought it was one of those ideas that’s so obviously right that we were all going to benefit from someone having just codified it and written it down.
So it's a breaking change?
Quote:
Here’s the problem: people interpret SemVer [numbering releases using the a.b.c convention] as permission to make breaking changes.
What's a breaking change? If, for example, it modifies a function's arguments but is well documented so that users can easily change their code, big deal. The other end of the spectrum is something that forces non-trivial rework in some applications.
Quote:
If you need to make a breaking change to your API, it means you screwed up.
Bzzt. At the trivial end, it means that the surface-to-volume ratio is being properly managed. No one can predict all future requirements. At the nasty end, it means consulting with users and giving them advance notice if a framework requires significant evolution in some area to better support new requirements. This article strikes me as 🐘ing entitled whining. People can stay on the current release if they don't want to put in the effort to evolve their software. Either that, or they chose the wrong vendor.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Quote:
Here’s the problem: people interpret SemVer [numbering releases using the a.b.c convention] as permission to make breaking changes.
What's a breaking change? If, for example, it modifies a function's arguments but is well documented so that users can easily change their code, big deal. The other end of the spectrum is something that forces non-trivial rework in some applications.
Quote:
If you need to make a breaking change to your API, it means you screwed up.
Bzzt. At the trivial end, it means that the surface-to-volume ratio is being properly managed. No one can predict all future requirements. At the nasty end, it means consulting with users and giving them advance notice if a framework requires significant evolution in some area to better support new requirements. This article strikes me as 🐘ing entitled whining. People can stay on the current release if they don't want to put in the effort to evolve their software. Either that, or they chose the wrong vendor.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
On the other hand, if I use a library A that depends on library B and library B makes a breaking change, I need to wait for library A to update its code before I can update to library B.
Even worse if you depend on libraries A and B, which both depend on C, but each depends on a different and incompatible version of C. X|
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
