Skip to content

Yanking policy clarification/discussion #679

@djc

Description

@djc

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).

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions