Then the past owner won’t be able to publish new crates anymore. It’s not different from a user losing access to their GitHub account, email account or crates.io account etc. Does it suck? Yes! Is it expected that this happens? Yes! Does this approach deal with it gracefully? Yes.
Migration can be accomplished by either
- supporting a
forward_to = "new.domain.org"attribute in Cargo.toml. This would also enable to creation of “awesome crates” collection crates, which only consist of forwarders to other crates.
- asking crates.io maintainers to create such a forwarder. (This is expected to be exceedingly rare. See the approach Maven took.)
That’s a policy question. There are multiple approaches with various degrees of automatism I can think of, let’s pick the one people feel most comfortable.
This proposal is significantly better than just letting users claim organizations and namespaces (like Maven does) because
- Maven does not allow any “choose-your-own” organizations or namespaces anymore as far as I know. There are some legacy artifacts left, but no new ones can be created (or at least heavily discouraged). Even old Apache Commons artifacts like commons-lang are slowly being migrated to domain-namespacing. Do you have contradicting information?
- “Claiming” in Maven space usually works by:
- manually creating a JIRA account on Sonatype
- writing a ticket, requesting a new project
- having some person manually review your request
- etc.: https://central.sonatype.org/pages/ossrh-guide.html
I proposed this approach, because I’m aware of how horribly Maven is when it comes to publishing artifacts. Using domains as namespaces (as Maven does) works exceedingly well, but many other parts of Maven are really really terrible mistakes that shouldn’t be repeated.
This triggers creation of your repositories. Normally, the process takes less than 2 business days.
Please do not deploy until after you have received an e-mail notice indicating that the ticket is Resolved . One of the most common problems related to new projects is premature deployment, which misroutes your artifacts to a catch-all repository.