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

Clearly note that unstable items in stable docs may be out of date #31204

Closed
lifthrasiir opened this issue Jan 26, 2016 · 9 comments
Closed

Clearly note that unstable items in stable docs may be out of date #31204

lifthrasiir opened this issue Jan 26, 2016 · 9 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.

Comments

@lifthrasiir
Copy link
Contributor

People seems to use the stable documentation to look for unstable items that are not available in the stable nevertheless. As per #25863 it is intentional, but then there remains a tough case of out-of-date documentation. In the IRC I have heard of one such example that the clone_from_slice method used to accept different slice lengths but since then updated to panic in such cases.

We cannot regenerate the stable documentation every time nightly updates, but we can probably link to the unstable documentation as the best effort. Something like this:

image

@steveklabnik
Copy link
Member

This also won't universally work, as sometimes, unstable features are removed and renamed. 👎 from me.

@steveklabnik steveklabnik added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Jan 26, 2016
@lifthrasiir
Copy link
Contributor Author

@steveklabnik You are right. But you can instead link to the search page as an alternative. Frankly, even the notice that it might not be current would be helpful; it is just an idea, after all.

@ollie27
Copy link
Member

ollie27 commented Jan 26, 2016

What about just removing unstable items from stable docs? I've never understood why they're included because they're always out of date as shown here and add unnecessary noise.

@rphmeier
Copy link
Contributor

@ollie27 That seems reasonable to me. It's not as if you can use unstable features from stable. I suppose the purpose is to inform users that they may have a solution if they are willing to use nightly, but it might create more confusion than it's worth.

@steveklabnik
Copy link
Member

We kept them in specifically so that you could see that something may be
added in the future and get involved in the conversation if the feature
matters to you.

On Tue, Jan 26, 2016 at 11:44 AM, Robert Habermeier <
notifications@github.com> wrote:

@ollie27 https://github.com/ollie27 That seems reasonable to me. It's
not as if you can use unstable features from stable. I suppose the purpose
is to inform users that they may have a solution if they are willing to use
nightly, but it might create more confusion than it's worth.


Reply to this email directly or view it on GitHub
#31204 (comment).

@steveklabnik steveklabnik added T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. and removed T-tools labels May 18, 2017
@Mark-Simulacrum Mark-Simulacrum added C-feature-request Category: A feature request, i.e: not implemented / a PR. C-enhancement Category: An issue proposing an enhancement or a PR with one. and removed C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Jul 24, 2017
@steveklabnik
Copy link
Member

Triage: no changes. Due to the stuff in my previous comments, I still think this is a bad idea, but I'll let @rust-lang/rustdoc decide that.

@GuillaumeGomez
Copy link
Member

I also think this is a bad idea. It can't be applied generally on the std lib.

@QuietMisdreavus
Copy link
Member

I generally agree with @steveklabnik and @GuillaumeGomez. It's not worth trying to add mapping information if an unstable item is moved, renamed, or deleted, since the stable docs are generated once, upon release, and never touched afterward. Attempting to add this mapping information would result in noisy backports that only serve to provide information for something that's not useful to stable users anyway.

However, there may be a way to salvage the issue, if we don't have to link to the actual item. Would it suffice to add a generic note like "Please note the item may be different on the [nightly docs]," where the link points to the root of the nightly docs, instead of the item itself? That would be much easier to add.

@ehuss ehuss removed the T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. label Jan 18, 2022
@Dylan-DPC
Copy link
Member

Closing this as the team is not in favour of this

@Dylan-DPC Dylan-DPC closed this as not planned Won't fix, can't repro, duplicate, stale May 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. 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

9 participants