Why deprecating types is considered a breaking change?

[jcornaz]

Today after deprecating some of structs, cargo semver-checks failed with this message:

--- failure type_marked_deprecated: #[deprecated] added on type ---

Description:
A type is now #[deprecated]. Downstream crates will get a compiler warning when using this type.
        ref: https://doc.rust-lang.org/reference/attributes/diagnostics.html#the-deprecated-attribute
       impl: https://github.com/obi1kenobi/cargo-semver-checks/tree/v0.37.0/src/lints/type_marked_deprecated.ron

This is quite surprising to me, as I never considered deprecation to be a breaking change, because it only creates warnings to downstream crates. But the downstream crates will still continue to compile and work correctly.

I'd be interested to understand the rationale for this behavior.

[obi1kenobi]

Hi! It isn't breaking — the cargo-semver-checks output should have ended with:

     Summary semver requires new minor version: 0 major and 1 minor checks failed

It's asking you to consider making a minor version bump, not major. With default cargo-semver-checks settings, causing new warnings in downstream code will require a minor bump. This is a default we chose based on the fact that many projects run with -D warnings in CI (so this would be breaking to them), and based on a poll of our user base when introducing the first few lints in this category where "require a minor version" won by a large margin.

If you don't like this lint, you can use lint configuration to lower it to a warning or make it skipped altogether.

[jcornaz]

Thank you very much for the answer. I'll check out those settings.

Note that, I did intend to bump the "minor" version. Or to be more precise, because my library is currency zero-ver, I intended to bump the "patch" version because that is what corresponds to a "minor", non-breaking change of a rust crate that has not yet reached 1.0.0.

Technically semver also requires bumping the minor version when anything is added to the API. Will cargo-semver-checks also require a minor bump for function/struct/module/trait/impl added in the future?

based on a poll of our user base when introducing the first few lints in this category where "require a minor version" won by a large margin.

Could you give a link to that discussion/poll? I'm interested to read the people's opinions and arguments :-)

[obi1kenobi]

Note that, I did intend to bump the "minor" version. Or to be more precise, because my library is currency zero-ver, I intended to bump the "patch" version because that is what corresponds to a "minor", non-breaking change of a rust crate that has not yet reached 1.0.0.

Right, we use cargo's definition of "major" and "minor" which ignores leading zeroes, since that's what ultimately governs cargo update behavior. So 0.1 -> 0.2 is a major bump, and 0.1.0 -> 0.1.1 is a minor bump etc.

If you bumped the minor version and still got that lint output, that would be a bug and I'd love a repro.

Will cargo-semver-checks also require a minor bump for function/struct/module/trait/impl added in the future?

We do plan to offer those lints eventually (though breaking change lints are our primary focus right now). We have not made a decision on what the default settings for them will be: deny, warn, or allow (i.e. completely opt-in). If you have an opinion on it, I'd love to hear it — it would probably be worth its own discussion issue.

Could you give a link to that discussion/poll? I'm interested to read the people's opinions and arguments :-)

No arguments were shared IIRC, it was just an informal social media poll where several dozen people just left a vote. Twitter search is terrible so I'm not able to find it at the moment =/

[jcornaz]

Ok. It makes sense. Thanks for the precisions.

If you bumped the minor version and still got that lint output, that would be a bug and I'd love a repro.

I didn't. I only intended to. I run cargo semver-checks for each commit, but I only bump the version in Cargo.toml when I release. So, I guess all I have to do is adapt my workflow to bump the version in Cargo.toml when I make changes instead of when I release. 😃

[obi1kenobi]

Ah that makes sense 👍

The current GitHub Action is best suited to be run right before release. But one of our contributors is currently working on a new action that will be suitable for running on each PR or commit, and comparing to the PR head branch instead of to crates.io. So hopefully we'll have a better workflow for you soon! 🤞