3 ms·

This is why I don't like semantic versioning. Semantic versioning only covers the "public API" but even the smallest "patch" change can result in a change in be

This is why I don't like semantic versioning. Semantic versioning only covers the "public API" but even the smallest "patch" change can result in a change in behaviour which has a big impact on the users.

eptcyka 2y ago
I have maybe seen it once when semver was being used.
- Ygg2 2y ago
  Here is another. Serde moving to binary blobs. - Does it alter API? No. - Does it change behavior? No. - Does it alter a public promise? No. - Is it SemVer violation? Nope. What is the problem then? Reproducible builds of NixOS and similar Linux distros fail.
  - eptcyka 2y ago
    Not serde, but newer version of rust, no? Nope, checking GitHub, I can’t see any issues about either of those two things combined with blobs. Also, the blobiness was never going to be a part of the public facing API - is it really the hypothetical serde’s fault NixOS breaks? I love NixOS, but the hacks they do to injevt determinism are obviously built on implementation details that most upstream projects need to keep opaque to continue improving. I’d much rather see upstream collaborate instead of have nix pees dictate that all current observed behaviour of any piece of software must be set in stone from the first reference in nixpkgs.
    - Ygg2 2y ago
      > Not serde, but newer version of rust, no? No, that's a separate issue in 1.80. See https://internals.rust-lang.org/t/type-inference-breakage-in-1-80-has-not-been-handled-well/21374/46 https://internals.rust-lang.org/t/type-inference-breakage-in... Issue was: new type inference caused problems for old version of the time crate. Newer versions worked with 1.80, but many crates weren't updated to the latest. > Also, the blobiness was never going to be a part of the public facing API - is it really the hypothetical serde’s fault NixOS breaks? According to Semver - no. According to people affected - yes. I often state this, but: Backwards compatibility ⇒ Semver (read: Backwards compatibility implies SemVer, but not the other way around). Who's right? Is it fine to speed up compilation but disrupt people using serde on Arch? It depends. According to strict Backwards compatibility guarantee - no. However according to them, you need to backport bugs and exploits.
poincaredisk 2y ago
This is covered in the spec. "Use your best judgement" is the answer. What's the other solution? Just give up and version you software sequentially/by timestamp?
Joker_vD 2y ago
On the other hand, I've seen some Go libraries explicitly dropping support for old Go versions in their "patch"-level releases. So some developers clearly consider being now unable to compile the library a backwards-compatible change.

eptcyka 2y ago

I have maybe seen it once when semver was being used.

Ygg2 2y ago
Here is another. Serde moving to binary blobs. - Does it alter API? No. - Does it change behavior? No. - Does it alter a public promise? No. - Is it SemVer violation? Nope. What is the problem then? Reproducible builds of NixOS and similar Linux distros fail.
- eptcyka 2y ago
  Not serde, but newer version of rust, no? Nope, checking GitHub, I can’t see any issues about either of those two things combined with blobs. Also, the blobiness was never going to be a part of the public facing API - is it really the hypothetical serde’s fault NixOS breaks? I love NixOS, but the hacks they do to injevt determinism are obviously built on implementation details that most upstream projects need to keep opaque to continue improving. I’d much rather see upstream collaborate instead of have nix pees dictate that all current observed behaviour of any piece of software must be set in stone from the first reference in nixpkgs.
  - Ygg2 2y ago
    > Not serde, but newer version of rust, no? No, that's a separate issue in 1.80. See https://internals.rust-lang.org/t/type-inference-breakage-in-1-80-has-not-been-handled-well/21374/46 https://internals.rust-lang.org/t/type-inference-breakage-in... Issue was: new type inference caused problems for old version of the time crate. Newer versions worked with 1.80, but many crates weren't updated to the latest. > Also, the blobiness was never going to be a part of the public facing API - is it really the hypothetical serde’s fault NixOS breaks? According to Semver - no. According to people affected - yes. I often state this, but: Backwards compatibility ⇒ Semver (read: Backwards compatibility implies SemVer, but not the other way around). Who's right? Is it fine to speed up compilation but disrupt people using serde on Arch? It depends. According to strict Backwards compatibility guarantee - no. However according to them, you need to backport bugs and exploits.

poincaredisk 2y ago

This is covered in the spec. "Use your best judgement" is the answer. What's the other solution? Just give up and version you software sequentially/by timestamp?

Joker_vD 2y ago

On the other hand, I've seen some Go libraries explicitly dropping support for old Go versions in their "patch"-level releases. So some developers clearly consider being now unable to compile the library a backwards-compatible change.