4 ms·

No, it really shouldn't be. It makes it impossible to distinguish between those "theoretically this a breaking change" kind of changes and the "you're going to

by slaymaker1907 5y ago

No, it really shouldn't be. It makes it impossible to distinguish between those "theoretically this a breaking change" kind of changes and the "you're going to need to rewrite a bunch of code" kind of changes. At the very least libraries should be allowed to define how the library must be used in order for their semantic versioning to apply. For languages which allow "import * from x" style imports, the library should still be allowed to add in new functions without that being a breaking change. If you want your software to be pristine forever, you really need to pin your dependencies, ideally via copying the source of the library into your repo so you aren't reliant on a package manager being available in the future. For library developers, regardless of versioning scheme you need to avoid ANY breaking changes whatsoever. Instead of changing an existing function, introduce a new one so that your downstream users can still access the old behavior while keeping up to date. Trust me when I say this will be much easier most of the time than patching old versions with security updates and bug fixes.

paskozdilar 5y ago
API is API. Either a library implements it or not. There is no room for "just this small API change uwu" in large-scale development.
- usrusr 5y ago
  That way the land of "n.0.0" versioning lies, where only the major is ever incremented, even for changes that won't affect anyone because the code that would be incompatible hasn't been written yet. At least for typed languages where an incompatibility clearly caught at compile time is usually preferable over a murky "technically it's still the same API, but..." I'd rather have separate numbers for major incompatibility/minor incompatibility.
  - paskozdilar 5y ago
    Incompatibilities happen, APIs evolve. It's a fact of life. Semver helps communicate those incompatibilities to people who care about it. If you don't want to freeze your API, then just use 0.X.Y, everyone will understand that they need to do regular maintenance if they want to use your code. But please, I beg you, do not use version 1+ if you're not planning to keep the compatibility promise.
    - usrusr 5y ago
      APIs evolve, sometimes in small steps and sometimes with major changes. Pedantic semver fails at communicating that difference.
      - paskozdilar 5y ago
        What difference does semver fail to communicate, exactly?

paskozdilar 5y ago

API is API. Either a library implements it or not. There is no room for "just this small API change uwu" in large-scale development.

usrusr 5y ago
That way the land of "n.0.0" versioning lies, where only the major is ever incremented, even for changes that won't affect anyone because the code that would be incompatible hasn't been written yet. At least for typed languages where an incompatibility clearly caught at compile time is usually preferable over a murky "technically it's still the same API, but..." I'd rather have separate numbers for major incompatibility/minor incompatibility.
- paskozdilar 5y ago
  Incompatibilities happen, APIs evolve. It's a fact of life. Semver helps communicate those incompatibilities to people who care about it. If you don't want to freeze your API, then just use 0.X.Y, everyone will understand that they need to do regular maintenance if they want to use your code. But please, I beg you, do not use version 1+ if you're not planning to keep the compatibility promise.
  - usrusr 5y ago
    APIs evolve, sometimes in small steps and sometimes with major changes. Pedantic semver fails at communicating that difference.
    - paskozdilar 5y ago
      What difference does semver fail to communicate, exactly?