google / google/zerocopy

Yanking policy clarification/discussion

Open
#679 15 comments 0 reactions 1 assignee Claimed by @joshlf View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.