Consider automatic CI check for breaking API changes
- Dominant language
- Rust
- Stars
- 3.6k
- Forks
- 1.3k
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 169
Description
**Is your feature request related to a problem or challenge? Please describe what you are trying to do.**
As part of the discussion about release cadence in https://github.com/apache/arrow-rs/issues/5368, what continually comes up is "when do we introduce breaking API changes" and "what effect does maintaining the check / discipline of avoiding the breakage have on maintainer bandwidth"
Specifically, carefully evaluating all PRs to see if they have breaking API changes is non trivial and error prone, and thus increases maintenance cost.
**Describe the solution you'd like**
I would like to implement some sort of automated CI check that verifies semver compatibility and flags the PR appropriately if there is an API change
**Describe alternatives you've considered**
Perhaps we can try using one of the following crates
* https://github.com/obi1kenobi/cargo-semver-checks
* https://github.com/Enselic/cargo-public-api
**Additional context**
Contributor guide
Research direction
The issue names no files, tests, or CI entry points. Start by comparing cargo-semver-checks and cargo-public-api, then determine how an automated check should verify semver compatibility and flag API-changing pull requests. Done means the chosen approach is integrated into CI with clear behavior for compatible and breaking changes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- ci-cd
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100