Skip to content

Commit 6243e9b

Browse files
authored
Merge pull request #172 from epage/pub-priv
Propose public/private dependency stabilization for 2025h1
2 parents f88e5ac + cbe0912 commit 6243e9b

File tree

1 file changed

+71
-0
lines changed

1 file changed

+71
-0
lines changed

src/2025h1/pub-priv.md

Lines changed: 71 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
1+
# Stabilize public/private dependencies
2+
3+
| Metadata | |
4+
| -------- | ------------------------------------------------------------ |
5+
| Owner(s) | ![Help wanted][] |
6+
| Teams | [cargo], [compiler] |
7+
| Status | Proposed |
8+
9+
## Summary
10+
11+
Find a MVP for stabilization and move it forwardc.
12+
13+
## Motivation
14+
15+
This will allow users to tell Rustc and Cargo what dependencies are private
16+
- Help users catch ways they unexpectedly expose their implementation details
17+
- Help tooling better identify what all consistutes an API
18+
19+
### The status quo
20+
21+
[RFC #1977](https://github.com/rust-lang/rfcs/pull/1977) has been superseded by
22+
[RFC #3516](https://github.com/rust-lang/rfcs/pull/3516) to reduce complexity on the Cargo side to help get this over the line.
23+
However, there is still a lot of complexity on the compiler side to get this right
24+
(
25+
[rust#3516](https://github.com/rust-lang/rfcs/pull/3516),
26+
[rust#119428](https://github.com/rust-lang/rust/issues/119428),
27+
),
28+
keeping this feature in limbo
29+
30+
### The next 6 months
31+
32+
Work with [compiler] to identify a minimal subset of functionality for what the lint can do and close out the remaining stabilization tasks.
33+
34+
### The "shiny future" we are working towards
35+
36+
## Design axioms
37+
38+
- False negatives are likely better than false positives
39+
40+
## Ownership and team asks
41+
42+
*This section defines the specific work items that are planned and who is expected to do them. It should also include what will be needed from Rust teams. The table below shows some common sets of asks and work, but feel free to adjust it as needed. Every row in the table should either correspond to something done by a contributor or something asked of a team. For items done by a contributor, list the contributor, or ![Heap wanted][] if you don't yet know who will do it. For things asked of teams, list ![Team][] and the name of the team. The things typically asked of teams are defined in the [Definitions](#definitions) section below.*
43+
44+
| Subgoal | Owner(s) or team(s) | Notes |
45+
| ---------------------------------------------- | ----------------------- | ----- |
46+
| Discussion and moral support | ![Team][] [cargo], [compiler] | |
47+
| Work through #3516, #119428 | ![Help wanted][] | |
48+
| Finish any remaining tasks | ![Help wanted][] | |
49+
| Mentoring | @epage | |
50+
| Stabilization report | ![Help wanted][] | |
51+
52+
### Definitions
53+
54+
Definitions for terms used above:
55+
56+
* *Discussion and moral support* is the lowest level offering, basically committing the team to nothing but good vibes and general support for this endeavor.
57+
* *Author RFC* and *Implementation* means actually writing the code, document, whatever.
58+
* *Design meeting* means holding a synchronous meeting to review a proposal and provide feedback (no decision expected).
59+
* *RFC decisions* means reviewing an RFC and deciding whether to accept.
60+
* *Org decisions* means reaching a decision on an organizational or policy matter.
61+
* *Secondary review* of an RFC means that the team is "tangentially" involved in the RFC and should be expected to briefly review.
62+
* *Stabilizations* means reviewing a stabilization and report and deciding whether to stabilize.
63+
* *Standard reviews* refers to reviews for PRs against the repository; these PRs are not expected to be unduly large or complicated.
64+
* *Prioritized nominations* refers to prioritized lang-team response to nominated issues, with the expectation that there will be *some* response from the next weekly triage meeting.
65+
* *Dedicated review* means identifying an individual (or group of individuals) who will review the changes, as they're expected to require significant context.
66+
* Other kinds of decisions:
67+
* [Lang team experiments](https://lang-team.rust-lang.org/how_to/experiment.html) are used to add nightly features that do not yet have an RFC. They are limited to trusted contributors and are used to resolve design details such that an RFC can be written.
68+
* Compiler [Major Change Proposal (MCP)](https://forge.rust-lang.org/compiler/mcp.html) is used to propose a 'larger than average' change and get feedback from the compiler team.
69+
* Library [API Change Proposal (ACP)](https://std-dev-guide.rust-lang.org/development/feature-lifecycle.html) describes a change to the standard library.
70+
71+
## Frequently asked questions

0 commit comments

Comments
 (0)