feat(ci): ensure exactly one version bump

[elenaf9]

Description

Check in CI that the version of a crate has been bumped exactly once since the last release.

Based on discussion in #5781.

Notes & open questions

Current solution feels a bit hacky. Does anyone know a better way to solve this?

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• A changelog entry has been made in the appropriate crates

[elenaf9]

(Doing a couple of test commits now to see if the CI catches wrong version bumps; will drop these commits later)

[elenaf9]

Ahh it seems like for some packages there hasn't been a git tag created last time they were released. E.g. libp2p-floodsub is v0.45.0 on crates.io, but the newest git tag for it is libp2p-floodsub-v0.44.0.

Unfortunately this breaks the CI check, since the check is using git tags so see what the latest released version is.
Originally I wanted to use cargo search for that, but that's not available / supported in the CI.

Unless there is an alternative idea to solve this I think the PR has to wait until the next release.

[jxs]

Hi Elena, can't we create those tags? Should be easy to find which commits match the releases.
If you list the missing tags I can do it

[elenaf9]

So the CI (scripts/ensure-version-bump-and-changelog.sh) now checks that:

• there has been a version bump if there is a diff in the crate's code (already existed prior to this PR): see failing CI check for libp2p-quic
• there is only a single version bump since the last release: see failing CI check for libp2p-relay
• the patch version is back to 0 if there was a minor version bump: see failing CI check for libp2p-server and libp2p-tls

It still feels a bit messy (well, it's bash....), but I wasn't able to come up with a better solution that checks all of the above criteria. Again, alternative suggestions are welcome.

[jxs]

So the CI (scripts/ensure-version-bump-and-changelog.sh) now checks that:

• there has been a version bump if there is a diff in the crate's code (already existed prior to this PR): see failing CI check for libp2p-quic
• there is only a single version bump since the last release: see failing CI check for libp2p-relay
• the patch version is back to 0 if there was a minor version bump: see failing CI check for libp2p-server and libp2p-tls

It still feels a bit messy (well, it's bash....), but I wasn't able to come up with a better solution that checks all of the above criteria. Again, alternative suggestions are welcome.

Thanks Elena! I think thi is good enough for our needs, we should after probably focus on releasing from github action, so that we ensure that tags are created and it will also probably help us with the release hierarchy of the sub-crates

[jxs]

this is for testing purposes right?