I'd like to solicit feedback on what Cargo's documentation should do regarding the [badges] table in Cargo.toml. Badges from the manifest are no longer displayed on crates.io (maintainers are encouraged to add badges to their README if they want them displayed). I'm wondering if there is any value in telling users about the [badges] feature that is mostly not used. Does anyone know of any projects which inspect the badges table?
It might also be useful to separate discussion of the "maintenance" badges from the other badges. There is some ongoing work and open issues about improving the maintenance status on crates.io. There are two parts to this, one is to provide an SVG endpoint to return the maintenance badge. The other is to make the maintenance status part of the database so that maintainers can modify it without publishing a new version. This isn't implemented, but I believe the intent is to use the "maintenance" status from Cargo.toml as the default if the user hasn't set the status in the web interface.
I'd like to propose removing the documentation for all badges except for the maintenance badge for now. Since crates.io will no longer be paying attention to the other badges, new services will not be added, and old ones will not be updated. The future of maintenance is still uncertain, but it seems like there is enough interest to keep it around for now. Does this sound like a reasonable course of action for now?
I'd like to keep discussion focused on what to do with documentation today, and not what crates.io should be doing, or how something like the maintenance status should be expressed or updated.
cc @kornel, I believe lib.rs is using the badges as a ranking indicator, please let me know if this would have a significant impact for you.
I can live without the badge data, and I wouldn't mind if it was buried. It's nice-to-have data, but my experience with lib.rs was that all author-provided metadata is sparse and unreliable (e.g. forked crates leave original crate's badges). In this case I could switch to checking APIs of known CI services and/or look for CI links in the README.
Ability to deprecate a crate is important, so I'm looking forward crates-io improvements in this area. For lib.rs I have an ugly big list of strings to match against crate description, such as "DEPRECATED." "Don't use this", "this crate is abandoned". It'd be great to replace it with definitive data from crates-io.
BTW: many crates are abandoned/deprecated, because they've been renamed or obsoleted by another crate. If you're adding maintenance status, please add "see also" link for redirecting to a replacement crate.
I just discovered this capability via the cargo-readme crate. It uses this information to autogenerate badge information in the README.md file.
what Cargo's documentation should do regarding the [badges] table in Cargo.toml
It would be great to have at least a link to a list of possible badge values--this is the information I am currently searching for (have not yet found) and would have liked to have discovered via the Cargo Manifest page. For clarity, I am not suggesting the canonical list should be maintained in the Cargo Manifest page, but one or more links to resources to aid discovery would be most welcome.
After searching extensively, I found the above reference to the [badges] table. While it has been deprecated by crates.io, it may still be useable for cargo-readme. That said, looking at cargo-readme's own generated README.md, they added a badge manually by including it in their README.tpl file.
