Staging area for crate uploads

[d-e-s-o]

I believe it would be great to have sort of a staging area for crates.io. Currently it appears that once a crate is uploaded there is no going back/changing of it in any way, modulo publishing a new version of course.
While that is fine conceptually, for initial releases or changes impacting the README or other other things in major ways, it would be great if there was a way to try things out first, have an initial look with the possibility of adjusting things.
PyPi has a staging area for this purpose, which seemingly is just a different instance (different URL) that has the once-uploaded-no-more-changes restriction removed.

I am thinking that such a feature would benefit a great deal of people. Have I just not found it?

[d-e-s-o]

Case in point, I just uploaded a new version of my crate to https://crates.io/crates/gui. Turns out that the relative link that I embedded into README.md for some reason gets expanded to a wrong and non-existent file on github.com. That is absolutely not what I wanted and a possibility to inspect the result beforehand (I could see the result on github.com, but the link works correctly there!) would have given me the chance to fix the problem. Now I have to live with it until a new version is ready.

[dwijnand]

Another use case this solves is making multi-crate releases atomic. See rust-lang/cargo#6510 (comment) where CI observed a world where failure_derive v0.1.5 and failure v0.1.4 were the latest versions available, which broke CI because failure_derive v0.1.5 required a change released in failure v0.1.5.

[wigy-opensource-developer]

Exactly the problem I looked up this discussion for. A multi-crate repo was releasing a non-semver-compatible patch-release on all their crates and a cargo update caught versions halfway through. Spent more time than I would admit to get to a point where I did a second cargo update that fixed the compilation issues.