3 ms·

> Even if an API stays exactly the same, something about what it returns could subtly change This means the API did in fact change. But you're right of course,

> Even if an API stays exactly the same, something about what it returns could subtly change This means the API did in fact change. But you're right of course, sometimes we pick the wrong number to bump (major vs minor vs patch).

madeofpalk 3y ago
It depends what you consider your "API" to be. One developer's bug is another's contract. For Typescript in particular, which is nothing _but_ a type system, every change is going to be a breaking change.
- bombcar 3y ago
  Exactly - if your API makes a mistake somewhere, someone is depending on that mistake. So even if the API says “returns the number of chickens” and now correctly returns 5 when there are 5 instead of saying 4; that may break something.
- zzo38computer 3y ago
  > One developer's bug is another's contract. That is why you have major.minor.patch semantic versions. The documented and official contract is according to equal to major versions, and greater or equal to minor versions (and possibly the patch number as well); if you depend on a specific bug or internal function then you should use the exact full version number only, in order to avoid such a problem. A bug would be one example, but another example might be the sqlite3_test_control function in SQLite.
- noirscape 3y ago
  In other words, Hyrums Law[0] in action. [0]: With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.
jt2190 3y ago
And remember “we” is often you, the maintainers of the packages you rely on, the maintainers of the packages that they rely on, the maintainers of the packages that THEY rely on… All need to have lock-step agreement about what a “breaking” change is, and all need to have communicated it clearly. The result though is the same, semantic versioning or no: If something changed you must retest. This is why all that’s needed is a “do I need to retest?” flag. Major/minor/patch is irrelevant if you need to keep things working.

madeofpalk 3y ago

It depends what you consider your "API" to be. One developer's bug is another's contract. For Typescript in particular, which is nothing _but_ a type system, every change is going to be a breaking change.

bombcar 3y ago
Exactly - if your API makes a mistake somewhere, someone is depending on that mistake. So even if the API says “returns the number of chickens” and now correctly returns 5 when there are 5 instead of saying 4; that may break something.
zzo38computer 3y ago
> One developer's bug is another's contract. That is why you have major.minor.patch semantic versions. The documented and official contract is according to equal to major versions, and greater or equal to minor versions (and possibly the patch number as well); if you depend on a specific bug or internal function then you should use the exact full version number only, in order to avoid such a problem. A bug would be one example, but another example might be the sqlite3_test_control function in SQLite.
noirscape 3y ago
In other words, Hyrums Law[0] in action. [0]: With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

jt2190 3y ago

And remember “we” is often you, the maintainers of the packages you rely on, the maintainers of the packages that they rely on, the maintainers of the packages that THEY rely on… All need to have lock-step agreement about what a “breaking” change is, and all need to have communicated it clearly. The result though is the same, semantic versioning or no: If something changed you must retest. This is why all that’s needed is a “do I need to retest?” flag. Major/minor/patch is irrelevant if you need to keep things working.