Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Clarify when API change PRs can be blocked on ACP #67

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Clarify when API change PRs can be blocked on ACP #67

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
612b3ad
Mention that any reviewer might request a FCP
oskgo Jul 19, 2024
3ae36f2
Merge branch 'rust-lang:master' into master
oskgo Jul 19, 2024
8ae1562
Update src/development/feature-lifecycle.md
oskgo Jul 19, 2024
19cc5b3
Remove double spacing
oskgo Aug 2, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/development/feature-lifecycle.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ be merged and pass its eventual FCP.

You can create an ACP in the `rust-lang/libs-team` repo using [this issue template](https://github.com/rust-lang/libs-team/issues/new?assignees=&labels=api-change-proposal%2C+T-libs-api&template=api-change-proposal.md&title=%28My+API+Change+Proposal%29). This should include a sketch of the proposed API, but does not have to be the final design that will be implemented.

Note that an ACP is not strictly required: you can just go ahead and submit a pull request with an implementation of your proposed API, with the risk of wasted effort if the library team ends up rejecting this feature. However do note that this risk is always present even if an ACP is accepted, as the library team can end up rejecting a feature in the later parts of the stabilization process.
Most standard library additions should start with an ACP. That's particularly true for things with substantial ecosystem impact, like traits that other libraries would be expected to implement, or expansion of the standard library into new areas. An ACP is not strictly required: reviewers may approve small things in existing areas. But while you can just go ahead and submit a pull request with an implementation of your proposed API, it's common that a reviewer will decide to ask for an ACP anyway. Note also that the library team can end up rejecting a feature in the later parts of the stabilization process, regardless of accepted ACPs or PRs.

## API design exploration

Expand Down
Loading