3 ms·

"MINOR version when you add functionality in a backwards compatible manner" Impossible to guarantee and thus impossible to do SemVer.

by k__ 4y ago

8organicbits 4y ago
It's OK if systems are imperfect, they are still helpful even though exceptions may occur. Intent matters. You may even see backwards incompatible changes treated as bugs fixed in subsequent releases.
enragedcacti 4y ago
Almost all code is aspirational in terms of matching a spec, being backwards compatible, not having bugs, etc. Its meaningless to talk about what is guaranteed with respect to practically every piece of software in existence. What is important to a developer is "what is the risk that upgrading this software will break my deployment, and what do I gain from upgrading it", which semver relays to the developer to the best of the library author's ability.
jjav 4y ago
Functionality can always be added in a backward compatible manner, that is indeed the purpose of a minor release. If libfoo has two public interfaces, sing() and dance(), I can add a third interface walk() and publish a binary-compatible libfoo.so which your consuming code can link to without any concern, as your code isn't calling walk() before it existed.
- k__ 4y ago
  The moment you allow bugs, you can't ensure backwards compatible changes. That makes semver as good as any other scheme, including GitDate.
  - jjav 4y ago
    > The moment you allow bugs, you can't ensure backwards compatible changes. I'm not sure what this even means, unless you're talking of the joke of "someone depended on the bug"? A bug, by its very definition, means code that doesn't behave as the documented interface description states. Fixing bugs means correcting mistakes in the code so that now it does behave as documented. That's what patch releases do.
    - k__ 4y ago
      No, but if you say you don't break API in minor, but you have a bug that breaks API, then minor broke API.
      - jjav 4y ago
        Are you referring to the possibility of a minor release introducing a bug? Yes, of course that's possible, nobody is pretending humans are infallible. When it happens, just issue a patch release to that minor release to fix the bug. Versioning is about communicating intent, it's not a guarantee that nobody can ever make a mistake. But if you're constantly introducing bugs in minor releases, that's a sign of sloppy test infrastructure and it will motivate me to migrate away from such a library. But the occasional bug is normal, fix it quick and move on.

"MINOR version when you add functionality in a backwards compatible manner" Impossible to guarantee and thus impossible to do SemVer.

by k__ 4y ago

"MINOR version when you add functionality in a backwards compatible manner" Impossible to guarantee and thus impossible to do SemVer.

8organicbits 4y ago

It's OK if systems are imperfect, they are still helpful even though exceptions may occur. Intent matters. You may even see backwards incompatible changes treated as bugs fixed in subsequent releases.

enragedcacti 4y ago

Almost all code is aspirational in terms of matching a spec, being backwards compatible, not having bugs, etc. Its meaningless to talk about what is guaranteed with respect to practically every piece of software in existence. What is important to a developer is "what is the risk that upgrading this software will break my deployment, and what do I gain from upgrading it", which semver relays to the developer to the best of the library author's ability.

jjav 4y ago

Functionality can always be added in a backward compatible manner, that is indeed the purpose of a minor release. If libfoo has two public interfaces, sing() and dance(), I can add a third interface walk() and publish a binary-compatible libfoo.so which your consuming code can link to without any concern, as your code isn't calling walk() before it existed.

k__ 4y ago
The moment you allow bugs, you can't ensure backwards compatible changes. That makes semver as good as any other scheme, including GitDate.
- jjav 4y ago
  > The moment you allow bugs, you can't ensure backwards compatible changes. I'm not sure what this even means, unless you're talking of the joke of "someone depended on the bug"? A bug, by its very definition, means code that doesn't behave as the documented interface description states. Fixing bugs means correcting mistakes in the code so that now it does behave as documented. That's what patch releases do.
  - k__ 4y ago
    No, but if you say you don't break API in minor, but you have a bug that breaks API, then minor broke API.
    - jjav 4y ago
      Are you referring to the possibility of a minor release introducing a bug? Yes, of course that's possible, nobody is pretending humans are infallible. When it happens, just issue a patch release to that minor release to fix the bug. Versioning is about communicating intent, it's not a guarantee that nobody can ever make a mistake. But if you're constantly introducing bugs in minor releases, that's a sign of sloppy test infrastructure and it will motivate me to migrate away from such a library. But the occasional bug is normal, fix it quick and move on.