6 ms·

I skimmed through the API Compatibility section in the cargo semver docs https://doc.rust-lang.org/cargo/reference/semver.html#api-compatibility https://doc.rus

I skimmed through the API Compatibility section in the cargo semver docs https://doc.rust-lang.org/cargo/reference/semver.html#api-compatibility https://doc.rust-lang.org/cargo/reference/semver.html#api-co... and got excited about the list of rules they came up with for choosing right version for your release. Is there similar guidelines for other languages like Java or Python?

kibwen 3y ago
For Java it should be easy to create such a list, if it doesn't exist (even easier than for Rust, I assume). For Python, I think the dynamicity would make it hard to come up with anything other than a subjective set of basic, non-comprehensive guidelines (which still sounds useful, but not from the perspective of a tool like this).
- toolslive 3y ago
  I'm still struggling with this: def do_it(*args, **kwargs) -> None: ... You might keep the signature constant, but let the behaviour evaluate across versions, but semver-wise, you could consider that API unchanged.
obi1kenobi 3y ago
All those rules are derived from a much smaller set of rules that are easier to understand. In Rust, those rules are more or less "breaking changes require a major version, unless the breaking change could have been avoided by the caller by adding disambiguation ahead of time." More details here: https://predr.ag/blog/some-rust-breaking-changes-do-not-require-major-version/ https://predr.ag/blog/some-rust-breaking-changes-do-not-requ... Rust generally has more exceptions than most languages about which breaking changes are technically considered non-major, so writing such guidelines for Python or Java shouldn't be too difficult. The same tech and ideas that power `cargo-semver-checks` could also be repurposed for those languages as well. If a company is interested in sponsoring such work, I'd be happy to help build something like that!

kibwen 3y ago

For Java it should be easy to create such a list, if it doesn't exist (even easier than for Rust, I assume). For Python, I think the dynamicity would make it hard to come up with anything other than a subjective set of basic, non-comprehensive guidelines (which still sounds useful, but not from the perspective of a tool like this).

toolslive 3y ago
I'm still struggling with this: def do_it(*args, **kwargs) -> None: ... You might keep the signature constant, but let the behaviour evaluate across versions, but semver-wise, you could consider that API unchanged.

obi1kenobi 3y ago

All those rules are derived from a much smaller set of rules that are easier to understand. In Rust, those rules are more or less "breaking changes require a major version, unless the breaking change could have been avoided by the caller by adding disambiguation ahead of time." More details here: https://predr.ag/blog/some-rust-breaking-changes-do-not-require-major-version/ https://predr.ag/blog/some-rust-breaking-changes-do-not-requ... Rust generally has more exceptions than most languages about which breaking changes are technically considered non-major, so writing such guidelines for Python or Java shouldn't be too difficult. The same tech and ideas that power `cargo-semver-checks` could also be repurposed for those languages as well. If a company is interested in sponsoring such work, I'd be happy to help build something like that!