r? @WaffleLapkin

(teloxidebot has picked a reviewer for you, use r? to override)

So, we already have 8 major checks failed

I think most of the fails are "breaking changes we wanted to make". The exceptions are:

1. auto_trait_impl_removed — auto traits should be implemented for polling stuff
2. 65f693b added a private field instead of a public one

What is the workflow that semver-checks proposes in such cases?...

Idk :)

"..understand and forgive".

Needs some investigation

So, according to the author on mastadon (see the replies) this mode of using с-s-c is not supported (yet). We'll have to resort to running it before release (can this be at least partly automated?).

@syrtcevvi can you try looking into the unintentional breakage (fixing or at least opening issues)?

👋 cargo-semver-checks author here! Ping me anytime if you have questions or if anything doesn't work as well as it should.

65f693b added a private field instead of a public one

Just a note that the change there would still be breaking even if the field was public. The issue is that the struct could previously be constructed with a literal like so VideoChatEnded {} and adding any kind of field to it will break that.

It's usually a good idea to mark pub structs as #[non_exhaustive] to prevent them being constructed with literals even when none of their fields are private. Once a pub exhaustive struct has been added to the public API, any of these changes (including making it #[non_exhaustive]) are major and breaking.

@obi1kenobi yeah, I know. We don't add #[non_exhaustive] because we need to do breaking changes on API updates anyway for other reasons, so it's not a big problem. But thanks for the note :^)