No Updates. These were made quite a while ago and the author(s) has lost intrest. These crates are fine and if they are (still) usefull, will find a new maintainer. Usally the original author ist still somewhat around and transfers the project to somebody else or gives them enough access.
No Source. The author(s) accounts are deleted or the source code hosting disappeared. Maybe if the project was popular enough, somebody may have a public clone somewhere.
Reserved crates. Somebody reserved a name, but over a year later there is still no real release. Worst case scenario, the authors account is no longer available.
Old dependency. Some (very) nested crate is abandoned, but the dependend crates are still active.
So I have some questions from both scenarios:
1.1 Is it currently a problem if an maintainer does not respond?
1.2 Does crates.io transfer ownership if requested or do we simply wait until “word spreads” about the new fork?
2.1 Has crates.io an old clone or copy of the source?
2.2 Will the code become public domain if the author has not left any mark inside the source?
2.3 Should the crate have a flag/category so a searching user can spot it?
2.4 Or even look for a project to take over?
3.1 Will the slot be freed?
3.2 If somebody would like to take the slot, can it be transfered?
4.1 Should cargo or a plugin for it warn the user about the old dependency? Sometimes old code is just done and needs no update (e.g. hardware dependent acceleration code).
I think that if you have a good reason (no updates for X months, no answer) and ask @alexcrichton nicely, ownership of a crate (name) can be transferred.
All crates are stored as source code.
I would assume that if no license was given, it is _all rights reserved.
You can add keywords when publishing a crate. I think what you are asking for is a way to flag crates as "abandoned", a new feature for crates.io.
That's probably a good reason for 1.2.
I think cargo can warn you when using a yanked crate, but there is no current way to say a crate is deprecated otherwise. This could probably work with a "flag as abandoned" feature.
Needless to say, this must be handled carefully to avoid malicious takeovers of crates in widespread use. The time until takeover is possible should be correlated with the number of downloads/reverse dependencies.
One additional idea would be that the next version after a transfer must be semver-incompatible, which mitigates the risks of dependents blindly updating somewhat.
crates.io requires a license field before you can publish. The code will still be bound by that license, unless the author ever changes said license.
It's not likely to happen. I went through that exact process once, but was deferred to the Crates.io policy, which I admittedly had forgotten to look at. The relevant section:
A more case-by-case policy would be very hard to get right, and would almost certainly result in bad mistakes and and regular controversies.
Instead, we are going to stick to a first-come, first-served system. If someone wants to take over a package, and the previous owner agrees, the existing maintainer can add them as an owner, and the new maintainer can remove them.
This might be too heavy-handed, but what if crates.io imposed some type of “your crate must build” rule.
If your crate is not buildable on any of the three release channels (stable, beta, nightly), for X consecutive months, it becomes a candidate for removal (where the value of X is to be determined by the community)
Note: if the crate is not updated in a while, but is still buildable (and thus still useful), then it should be able to remain on crates.io indefinitely.
This should not happen with stable rust because the compiler guaranties backwards compatibility to 1.0.
Never the less, I do not belive in an automated process here. Plus disk storage is getting cheaper every day. So I would store it and maybe flag it so developers do not waste their time.
This isn't quite true - the stability guarantee is much weaker, especially around soundness bugs which require breaking changes to preserve the language's soundness.
I think it's a non-starter, driven by my own selfish requirements, libraries for running Rust on seL4. Building them requires custom target specifications and some toolchain setup. It'd be very sad for me to not be able to put these sorts of crates on crates.io, as they are otherwise stable (modulo needing to be built with nightly for one dep which uses inline asm for the kernel interface).
I agree, an automated aproach would damage more than it would help.
It appears very attractive, because of the fix a problem an forget about it feeling, but the ecosystem is changing rapidly and the method would be broken very soon or from the beginning because the model of the problem does not fit the real world.
I am fine with the current state for the forseeable future.
I could imagine a system where after X months without any new release the author would be sent an automatic mail asking if the crate is still maintained. If the author still maintains the crate he would just have to click on a given link (same style as email registration links) and that would reset the counter. If the author doesn’t respond within Y months then the crate could be flagged as unmaintained.
I think the cleanest solution is to never allow the takeover of crates where there still exists a user which has access to the crate. So as long as their github account wasn’t deleted, the crate cannot be taken over without action from the user.
If the license allows it or you reimplement the crate from scratch, you can always publish your crate under a new name and users will flock to you if it is an improvement.
What would help is to increase the visibility of maintained, used, compiling crates, by having them appear earlier in the search.
So the number of downloads in the last month and the age of the last update would be additional heuristics added to the “relevance” search.
Additionally, adding some way to display travis badges or the version of rustc used to upload that crate would help users decide between crates. (the latter should have a way to run cargo publish multiple times with the same version and code, but different compilers, so developers can show that their crate runs on older and newer rustc versions, as well as on stable/unstable.
