Add CI job to run cargo-semver-checks that will error if we make a breaking change to a patch or minor release.
Why
To monitor whether the changes being made to the soroban-sdk and its exports are a match for the version being targeted. The soroban-env-common and some of the guest and host crates are reexported by the soroban-sdk and essentially part of its API.
Due to issues outlined in the comment below these checks cannot all be done on the soroban-sdk:
Also, independent of the above not breaking semver rules is relatively important in the Rust ecosystem because cargo favors selecting newer (maximum) instead of older (minimum) versions. While lock files exist, they aren't respected by default in some contexts like cargo install meaning introducing breaking changes into a crate can break downstream tools. (We avoid this on the products we publish by pinning exact versions of the env, but that is not common practice in the Rust ecosystem.)
What
Add CI job to run cargo-semver-checks that will error if we make a breaking change to a patch or minor release.
Why
To monitor whether the changes being made to the soroban-sdk and its exports are a match for the version being targeted. The soroban-env-common and some of the guest and host crates are reexported by the soroban-sdk and essentially part of its API.
Due to issues outlined in the comment below these checks cannot all be done on the soroban-sdk:
Also, independent of the above not breaking semver rules is relatively important in the Rust ecosystem because cargo favors selecting newer (maximum) instead of older (minimum) versions. While lock files exist, they aren't respected by default in some contexts like
cargo installmeaning introducing breaking changes into a crate can break downstream tools. (We avoid this on the products we publish by pinning exact versions of the env, but that is not common practice in the Rust ecosystem.)Close stellar/rs-soroban-sdk#1195