4 ms·
In Rust, this is often done by using optional features, and usually features named like `unstable-<something>`. They are a form of conditional compilation: peop
by obi1kenobi 3y ago
In Rust, this is often done by using optional features, and usually features named like `unstable-<something>`. They are a form of conditional compilation: people that don't opt in don't see that code, and people that do opt in know the code is unstable.
`cargo-semver-checks` by default doesn't check for any semver obligations for code behind such features. (I'm its maintainer )
- epage 3y agoAnd we'd like to have native support for these in cargo: https://github.com/rust-lang/cargo/issues/10881 https://github.com/rust-lang/cargo/issues/10881
- o11c 3y agoThe problem with the current approach is that it does not specify whether `libfoo-1.2.3[unstable-bar]` is compatible with `libfoo-1.3.4[unstable-bar]`, nor whether the latter is compatible with `libfoo-1.4.5[default]`. (also I'm not sure under what circumstances recompilation is required)
- conradludgate 3y agoThe rust std lib doesn't make any commitments to unstable (nightly) APIs, so this is the norm.
- o11c 3y agoIt doesn't formally make commitments. But in practice for most particular APIs there is stability, and it is the job of tooling to support that.