Document process for breaking changes #69
Conversation
workingjubilee
force-pushed
the
add-process-change
branch
from
2d2ef06
to
7388b6d
Compare
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
| If a PR is merged and it turns out to have caused code to not compile during the nightly or beta release cycle, | ||
| unless there is a trivial fix, the PR should be reverted and a crater run should assess the impact. | ||
|
|
||
| ### Model: A Trivial Fix |
There was a problem hiding this comment.
AFAICT, this example is specifically about a nightly-only feature. It seems like it'd be a better example if we used a change that was visible to stable Rust code but that we mitigated, and how we mitigated it?
(Not trying to add substantial additional work here. And this example may still make sense as a guide for changes that only affect nightly.)
There was a problem hiding this comment.
@joshtriplett Actually the issue here is precisely that the change was visible to stable Rust code, i.e. the regression was heading to stable, but the feature was nightly. I can clarify that in the remarks if you like?
There was a problem hiding this comment.
Ah, I see. That does seem different from the case of a change where the change itself intentionally adds new stable API surface area, but I appreciate the clarification.
Proposed in T-libs-api meeting, Jul 09.
Accepted in T-libs-api meeting, Aug 20.