Yanking policy clarification/discussion
- Dominant language
- Rust
- Stars
- 2.6k
- Forks
- 179
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 29
Description
My project at work was affected by the yanking of 0.7.28 yesterday. I was curious about the reason (which wasn't trivial to find, since there don't seem to be any release notes) and ran into your new policy from #677:
> Whenever a bug or regression is identified, we will yank any affected versions
> which are part of the current version train. For example, if the most recent
> version is 0.10.20 and a bug is uncovered, we will release a fix in 0.10.21 and
> yank all 0.10.X versions which are affected. We *may* also yank versions in previous
> version trains on a case-by-case basis, but we don't guarantee it.
This doesn't have any language on whether there is a severity bar that a bug must meet before yanking will be done. IME yanking can be painful to downstream consumers (for example, we manage our lock files in version control and update them generally once a week, but use cargo-deny check to check for yanked crates, so this caused our CI to fail). It looks like the offending issue (in #672) was pretty serious, but it would be a pain if yanking started happening frequently (more than say once every few months).
Contributor guide
Assessment
This issue has not been assessed yet.