Hacker News new | past | comments | ask | show | jobs | submit login

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 )




And we'd like to have native support for these in cargo: https://github.com/rust-lang/cargo/issues/10881


The 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)


The rust std lib doesn't make any commitments to unstable (nightly) APIs, so this is the norm.


It 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: