enable cargo-semver-checks, try 2

[davidhewitt]

Closes #2984

Many thanks @obi1kenobi for completing support of #[doc(hidden)] in cargo-semver-checks; I tested on 0.17, 0.18 and 0.19 branches and the good news is that all our releases there were semver compliant 🚀

(I didn't try older branches 😂)

[davidhewitt]

Looks like this is behaving as expected; the only question IMO is do we go for 0.21.0-dev or just 0.21.0 in our Cargo.toml files?

[obi1kenobi]

Looks like this is behaving as expected; the only question IMO is do we go for 0.21.0-dev or just 0.21.0 in our Cargo.toml files?

From cargo-semver-checks' point of view, those should be the same (if they are not, please let me know or open an issue). So it's entirely your call.

At some point, I'm hoping to have a "proper" PR-oriented cargo-semver-checks action as well. The current one is designed to be put right before cargo publish which is why it treats semver violations as a job failure. A PR-oriented one would compare the target branch to the base branch, not to the previous release, and it would point out the changes that are breaking and/or assign labels to the PR like semver:major so as to allow maintainers to merge breaking changes without bumping the major version.

[davidhewitt]

That makes sense, I can see how on a non-release workflow this is still more of a lint. Also I suspect that once I've bumped the version on main, the semver-checks job will never fail again, thus limiting the per-PR feedback we'd get from it?

This will still be immensely helpful on maintenance release PRs to give me confidence that the stuff I've cherry-picked is not semver-breaking!

I'm going to go for 0.21.0-dev, as I like the ceremony of making a version bump at the point of release 😂

[obi1kenobi]

Also I suspect that once I've bumped the version on main, the semver-checks job will never fail again, thus limiting the per-PR feedback we'd get from it?

Exactly right! Another thing that would be solved with a PR-centric workflow.