Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rustdoc crate stable version number is misleading #41581

Closed
brson opened this issue Apr 27, 2017 · 3 comments
Closed

rustdoc crate stable version number is misleading #41581

brson opened this issue Apr 27, 2017 · 3 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@brson
Copy link
Contributor

brson commented Apr 27, 2017

Every release I verify the docs, and go to this page. Every release this page says, in big text at the top of the page, "1.0.0". Casual users will not understand what this label means - they will expect it to correspond to the current release.

I think this label provides little value (negative actually, considering this issue) - stability attributes only apply to in-tree crates, and the set of stable crates rarely changes.

I suggest removing this label and instead finding some way to indicate the version of the crate.

@brson brson added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Apr 27, 2017
@brson brson changed the title rustdoc crate stable version number is extremely misleading rustdoc crate stable version number is misleading Apr 27, 2017
@daniellockyer
Copy link
Contributor

How about something like the following?

2017-04-27-200515_681x270_scrot

@marti1125
Copy link
Contributor

@brson I would like to contribute with this

@steveklabnik steveklabnik added the T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. label May 18, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 27, 2017
@QuietMisdreavus
Copy link
Member

Closing as duplicate of #24336, since this is just that issue applied to the (very visible example of) libstd. (I left a hint in there, but the implementation details are slightly up to a team decision to make sure we don't couple too tightly to Cargo.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants