A tracking issue for a relatively small feature just launched an interesting conversation about a stabilization conundrum:
- There are plenty of features/APIs that are unstable, but are too minor for a library to consider switching to nightly Rust just for their sake. And with stable Serde, more and more of the ecosystem is using the stable compiler.
- We’re often flummoxed when considering potential stabilization, because we don’t have much feedback on the feature to go on.
It’s tempting to introduce some level of stability between unstable and stable, where we allow you to use the feature (behind a flag) on the stable compiler, but retain the freedom to change or remove the feature if circumstances demand it. The idea would be to do this only for features that are very close to stabilization.
But I can’t see my way around a fundamental issue here: it’s still possible for you to upgrade to a new stable version of Rust, and find that one of your transitive dependencies no longer compiles. This kind of situation is the root of dependency hell, and we’ve tried to architect policies precisely to avoid it. (With elaborate source for dependencies, and a semver analysis tool, we could get close to an iron-clad guarantee here).
Unless I’m missing something, this line of reasoning indicates that stable means stable; if we wish to ensure that you never dread updating Rust, we can only ship things on the stable compiler that we’re willing to support indefinitely.
Is there another way of seeing things, or some other avenue we could take to ensure that features get sufficient feedback?