[Meta] RELEASES.md isn't rendered on GitHub.com #101714
Comments
|
This is also being discussed on Zulip but it's good to have an issue to track it. |
|
Another thing that may be of interest is that the RELEASES.md file successfully renders on the GitHub Android App although it's a bit jittery. Problem might be web specific. |
|
@rustbot label +A-meta |
rustbot
added
the
A-meta
ehuss
added
the
T-release
|
Note that the pre-release testing blog post links to RELEASES.md on GitHub that fails to render for some people, and that does not feel good. |
|
A quick alternative -
|
|
Some other options for splitting it up:
|
|
I put up an MVP PR in #112135. |
This is a workaround for rust-lang#101714 on top of being a useful addition in its own right. It is intended to change the "canonical URL" for viewing the release notes from GitHub, which is relatively slow, to a pre-rendered HTML file that loads from the same CDN as the standard library docs. It also means you get a copy of the release notes when installing the rust-docs with rustup.
This is a workaround for rust-lang#101714 on top of being a useful addition in its own right. It is intended to change the "canonical URL" for viewing the release notes from GitHub, which is relatively slow, to a pre-rendered HTML file that loads from the same CDN as the standard library docs. It also means you get a copy of the release notes when installing the rust-docs with rustup.
This is a workaround for rust-lang#101714 on top of being a useful addition in its own right. It is intended to change the "canonical URL" for viewing the release notes from GitHub, which is relatively slow, to a pre-rendered HTML file that loads from the same CDN as the standard library docs. It also means you get a copy of the release notes when installing the rust-docs with rustup.
…-Simulacrum doc: add release notes to standalone doc bundle Preview: http://notriddle.com/rustdoc-html-demo-5/release-notes/releases.html This is a workaround for rust-lang#101714 on top of being a useful addition in its own right. It is intended to change the "canonical URL" for viewing the release notes from GitHub, which is relatively slow, to a pre-rendered HTML file that loads from the same CDN as the standard library docs. It also means you get a copy of the release notes when installing the rust-docs with rustup.
|
What if we change it from a Markdown file to a text file? Markdown is designed to be mostly-readable in text mode, so it wouldn't be that big of a change (nobody would have to go through and rewrite the whole file), and better to be able to read raw text rather than read nothing at all. As for breaking links, this will only break links that don't include the hash (remember you can press |
Now that https://dev-doc.rust-lang.org/1.76.0/releases.html exists, we can use it and not have to worry about rust-lang/rust#101714 any more. This is a follow-up for rust-lang/rust#117888
Now that https://dev-doc.rust-lang.org/1.76.0/releases.html exists, we can use it and not have to worry about rust-lang/rust#101714 any more. This is a follow-up for rust-lang/rust#117888
|
I must note that I don't what is the cause, but now the file is actually rendered all the way to 2012! So, looks like the issue might be solved on GitHub side, but I'd like an opinion of project management. |
|
We might want to consider moving future releases to different file(s), to prevent errors like that in the future. But the issue at hand indeed seems to be fixed on github side. Even though I'm no project management, I'm going to go ahead and close this. |
Hi, Rust contributors!
Take a look at Rust releases file: https://github.com/rust-lang/rust/blob/master/RELEASES.md. For me, GitHub just states that rendering it took too long, so it won't show it. In my opinion rendering Markdown shouldn't be so hard to render a rarely updated half-megabyte file, but it's to GitHub developers who are managing the platform and their workload might dictate the limits. However, even if the current file could be rendered, it will still continue to grow with each release.
I see several ways to tackle this problem:
1.*or1.2.*, and are created rarely, while fixes releases are much more often. Rust versions since 1.0 aren't like that, we for the most time just have incrementing minor version with rare bug-fixing releases. I have a quick thought that we could just aggregate those by 10 or by release a year, but it requires further thoughts on UX of the whole thing.RELEASES.md.Anyway, those are just my thoughts, and maybe tomorrow the file will still be viewable as it has been before.
The text was updated successfully, but these errors were encountered: