Currently crate releases appear immediately on crates.io. Users who don't have a lockfile get the release immediately. Users with lockfiles get it whenever they decide to update.
That's generally good enough, but sometimes I'd like to have more control:
As a crate author, sometimes I have bigger releases that could have bugs or compatibility issues. I publish -pre releases, but in practice very few users test them, so I hear about bugs when I make a "stable" release. In popular crates this breaks more users than necessary for me to get feedback. I'd love to have ability to make "canary" releases to a small percentage of users, or have a new release roll out gradually over a week or so.
As a user, I have some very sensitive projects that I need to be extra stable. A blanket cargo update can pull in both bug fixes (which I want) and new features with new bugs (which I don't want). There's rustsec and yanking for signalling critical updates, but other cases need to be evaluated manually.
cargo install has a dilemma whether to use lockfiles or not. With a lockfile, the installation is more predictable and less likely to be broken by some new incompatible dependency, but an installation without a lockfile is needed in case some updates have important compatibility and security fixes. Why not both?
So I imagine that Cargo registries could support declaring importance of releases. A release could be marked as urgent, and make tooling prioritise it. Or a release could be marked as unimportant or risky, and have a gradual rollout. Cargo could have different update strategies, like applying only updates marked as important (solving cargo install dilemma), randomly staggering/delaying unimportant releases, or eagerly updating everything to maximum.
Currently it's not easy to test pre-releases of crates, especially transitive dependencies, because a stable dependency (v1.1.0) can't be automatically updated to a pre-release (v1.2.0-rc).
If cargo update had a mode which bends the semver rules to include upcoming pre-releases, it could be used in CI for automatically trying out upcoming releases of crates, without needing any new features in the registry.
Personally, I'd also like a signal for the opposite end: to be able to mark a dependency as unimportant, "don't update this unless necessary or requested". This would serve two goals:
Reducing churn in cases where the package is unlikely to be involved in a vulnerability and used in narrow enough circumstances that preemptive bug fixes aren't wanted.
If it includes a mode where the package is never updated without explicit approval, it can mitigate the risk of depending on many small packages with little-known authors, by making it feasible to review every infrequent update to those packages while still auto-updating others.
This could be done today using a dummy package in the workspace with =1.2.3 pinned dependencies, but that doesn't allow reporting available updates for those packages distinctly from actually incompatible-version updates.
I'm a big believer in making dependency constraints as flexible as possible, to the point where I've actually experimented with using nothing but >= constraints, on the theory that even a major version bump has a decent chance of not breaking my particular usage. I want to see the language make it easier to set your minimum supported version of all your deps, including of Rust itself, as low as possible (for instance, with the #[cfg] minilanguage letting you query the existence of a specific path in a specific external crate). I want the industry at large to move away from lockfiles and toward automated analyses that produce ranges of dependency versions that are known to work.
These goals are complementary to both "declare importance of releases" and "declare importance of dependencies". What if there were automation that let a crate author pull all the newest versions of their dependencies, run the tests, and if something breaks, mark just the bad version of just the one (most likely) troublesome dependency as "don't use that one" in a way that would then get pushed out to the crate's users? That would, I think, make people a lot less reluctant to try updates that might or might not break something.
However, there can still be reasons that one may want to encourage a version or discourage a version. For the latter, we have yank. I feel like rustsec partially provides us the first. Having call graph analysis would be a big help to improve that further. If we extended that in a way that we could declare bugs on parts of the API and people could get notices that they may want to update if they care about that bug, then I feel like that could help cover this.
See the precise-pre-release unstable feature. The main question is the exact version requirement semantics because >=0.10,<0.11 would include pre-release versions when the user intended >=0.10,<0.11-0. We have an alternative set of semantics implemented for this feature that attempts to guess the users intent. For myself, I'd also love for us to not make this special cargo update behavior but to in general give users control over whether pre-releases are disallowed or to de-prioritize them over all other versions.