4 ms·

Semver will never "solve" the library dependency problem, because it is not a problem that can be "solved". We want 2 things out of dependency management. 1.

Semver will never "solve" the library dependency problem, because it is not a problem that can be "solved". We want 2 things out of dependency management. 1. If a new version of a dependency contains a desirable/necessary improvement (however that is defined), we want to automatically pick up the new version. 2. If upgrading to the new version will make things worse (however that is defined), we do not want to pick up the new version. But there is no automated way of determining which of those is the case sort of actually trying the new version and fully testing it, even in the presence of "proper" semantic versioning (or any other kind of metadata you might provide). - you may already have a workaround for the library bug in your code, so a non- interface-breaking fix in the library may break your usage until you remove the workaround. Semver can't help you with this because the library maintainer doesn't know about your workaround - an update may have both properties (fixed one thing, broke something else). Semver can't make the judgement call about whether the tradeoff is a net improvement or not - the update may change a behavior that is not formally guaranteed, but which your use has an (unknown to you) dependency on. So the semver can "correctly" label it as a non-breaking change, but it still breaks your use case. - etc. This doesn't mean semver is worthless. Knowing that something is definitely a breaking change because an API was removed or modified in an incompatible way will still save you time. But you still need to actually test to know if updating a dependency is actually safe.

obi1kenobi 3y ago
Of course! `cargo-semver-checks` is not a replacement for testing. It's exactly the kind of tool you describe: > Knowing that something is _definitely_ a breaking change because an API was removed or modified in an incompatible way will still save you time. We want to help maintainers spot accidental breaking changes early — before they are released — instead of both maintainers and downstream projects having to scramble for fixes after an accidental breaking change is released.
wnoise 3y ago
> Knowing that something is definitely a breaking change because an API was removed or modified in an incompatible way will still save you time. Iff it's a part of the API you use directly or indirectly. Sometimes you're only using part of it, and changes to the rest don't matter.
smrq 3y ago
Honestly, I don't know why people overthink it... a major bump means "your code probably has to change"; anything else means "your code probably doesn't have to change". That's more than good enough for me and beats the hell out of "no indication whatsoever whether your code has to change".
- vasvir 3y ago
  Yes but currently semver declaration happens in a best effort base by a human. The authors advocate that they can have the semver declaration test by a computer which unquestionably will increase the reliability of the declaration in the long run. It is like testing but for backward compatibility, which of course can be part of the testing infrastructure some day. I like their approach very much. What a great bachelor project... And the witness approach is great. Bonus points for the systematic approach. Congrats to all involved.
  - obi1kenobi 3y ago
    Thank you! I love mentoring people, and it was a privilege to work with these particularly talented and hard-working undergrads.
FreshStart 3y ago
You could do that kind of behavior with unit testing. If a dependency breaks a library, it just doesn't upgrade.

obi1kenobi 3y ago

Of course! `cargo-semver-checks` is not a replacement for testing. It's exactly the kind of tool you describe: > Knowing that something is _definitely_ a breaking change because an API was removed or modified in an incompatible way will still save you time. We want to help maintainers spot accidental breaking changes early — before they are released — instead of both maintainers and downstream projects having to scramble for fixes after an accidental breaking change is released.

wnoise 3y ago

> Knowing that something is definitely a breaking change because an API was removed or modified in an incompatible way will still save you time. Iff it's a part of the API you use directly or indirectly. Sometimes you're only using part of it, and changes to the rest don't matter.

smrq 3y ago

Honestly, I don't know why people overthink it... a major bump means "your code probably has to change"; anything else means "your code probably doesn't have to change". That's more than good enough for me and beats the hell out of "no indication whatsoever whether your code has to change".

vasvir 3y ago
Yes but currently semver declaration happens in a best effort base by a human. The authors advocate that they can have the semver declaration test by a computer which unquestionably will increase the reliability of the declaration in the long run. It is like testing but for backward compatibility, which of course can be part of the testing infrastructure some day. I like their approach very much. What a great bachelor project... And the witness approach is great. Bonus points for the systematic approach. Congrats to all involved.
- obi1kenobi 3y ago
  Thank you! I love mentoring people, and it was a privilege to work with these particularly talented and hard-working undergrads.

FreshStart 3y ago

You could do that kind of behavior with unit testing. If a dependency breaks a library, it just doesn't upgrade.