|
| 1 | +# RustAPI Contract |
| 2 | + |
| 3 | +This document defines compatibility guarantees for the RustAPI workspace. |
| 4 | + |
| 5 | +## 1. Scope |
| 6 | + |
| 7 | +- Stable public contract: |
| 8 | + - `rustapi-rs` (facade crate) |
| 9 | + - `cargo-rustapi` (CLI surface) |
| 10 | +- Internal implementation crates (best-effort, no stability guarantee): |
| 11 | + - `rustapi-core`, `rustapi-openapi`, `rustapi-validate`, `rustapi-macros` |
| 12 | + - `rustapi-extras`, `rustapi-ws`, `rustapi-toon`, `rustapi-view`, `rustapi-grpc` |
| 13 | + - `rustapi-testing`, `rustapi-jobs` |
| 14 | + |
| 15 | +Do not depend on internal crate APIs for long-term compatibility. |
| 16 | + |
| 17 | +## 2. SemVer Policy |
| 18 | + |
| 19 | +- `rustapi-rs` follows strict SemVer: |
| 20 | + - Breaking changes: major |
| 21 | + - Additive changes: minor |
| 22 | + - Fixes/internal-only changes: patch |
| 23 | +- Public API surface is tracked by committed snapshots: |
| 24 | + - `api/public/rustapi-rs.default.txt` |
| 25 | + - `api/public/rustapi-rs.all-features.txt` |
| 26 | +- Pull requests that change snapshots must be labeled: |
| 27 | + - `breaking` (if compatibility breaks) |
| 28 | + - `feature` (if additive API surface change) |
| 29 | + |
| 30 | +## 3. MSRV Policy |
| 31 | + |
| 32 | +- Workspace MSRV is pinned to Rust `1.78`. |
| 33 | +- MSRV increases are allowed only in minor or major releases. |
| 34 | +- MSRV changes must be called out in changelog/release notes. |
| 35 | +- Patch releases must not raise MSRV. |
| 36 | + |
| 37 | +## 4. Deprecation Policy |
| 38 | + |
| 39 | +- Deprecations are soft-first: |
| 40 | + - `#[deprecated]` attribute |
| 41 | + - explicit migration path in docs/release notes |
| 42 | +- Minimum deprecation window before removal: 2 minor releases. |
| 43 | +- Removals occur only in major releases. |
| 44 | +- Current compatibility window for legacy aliases introduced in this cycle: |
| 45 | + - First eligible removal: `v0.3.0` (assuming deprecation introduced in `v0.1.x`). |
| 46 | + |
| 47 | +## 5. Feature Flag Policy |
| 48 | + |
| 49 | +- New facade feature names must follow taxonomy: |
| 50 | + - `core-*` |
| 51 | + - `protocol-*` |
| 52 | + - `extras-*` |
| 53 | +- Meta features: |
| 54 | + - `core` (default) |
| 55 | + - `protocol-all` |
| 56 | + - `extras-all` |
| 57 | + - `full` |
| 58 | +- Legacy aliases may exist temporarily for migration but must be treated as deprecated and eventually removed on a published timeline. |
| 59 | +- Published timeline for this migration set: |
| 60 | + - `v0.1.x`: aliases available, deprecation warnings/documentation. |
| 61 | + - `v0.2.x`: aliases still available, migration reminders. |
| 62 | + - `v0.3.0+`: aliases may be removed. |
| 63 | + |
| 64 | +## 6. Internal Leakage Rule |
| 65 | + |
| 66 | +- Public facade signatures should not expose internal crate paths. |
| 67 | +- Macro/runtime internals are allowed only via `rustapi_rs::__private` and are excluded from stability guarantees. |
0 commit comments