Rust 1.70.0 pre-release testing

system · May 29, 2023, 9:30pm

The 1.70.0 pre-release is ready for testing. The release is scheduled for June 1. Release notes can be found here.

You can try it out locally by running:

RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup update stable

The index is https://dev-static.rust-lang.org/dist/2023-05-29/index.html.

The release team is also thinking about changes to our pre-release process: we'd love your feedback on this GitHub issue.

hehaoqian · May 31, 2023, 1:25am

Better reduce the size of RELEASES.md? https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1700-2023-06-01 Github errors with This blob took too long to generate.

quinedot · May 31, 2023, 1:38am

github.com/rust-lang/rust

[Meta] RELEASES.md isn't rendered on GitHub.com

opened 09:19AM - 12 Sep 22 UTC

LDVSOFT

T-release A-meta

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: * Keep things as they are right now. Even if Releases isn't viewable on the GitHub website, you can still read it sources or view in editor/IDE that can show rendered MarkDown, and I guess releases blog posts are very similar to a separate chapter of that file. * Contact GitHub team, maybe they could provide a solution or advice from their side. * Split RELEASES.md. file. Several other projects use several Releases / ChangeLog files, so that every one of those isn't that big. However, it often comes from the fact that they have a deeper versioning scheme, where every file represents one major or minor series, i.e. `1.*` or `1.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. * What we could do is to add just one "older releases" and only keep several recent ones (like, for a year) in a `RELEASES.md`. Anyway, those are just my thoughts, and maybe tomorrow the file will still be viewable as it has been before.

djc · May 31, 2023, 12:08pm

I've put up a PR for this. The Zulip thread linked from there also discusses some other options to improve on the current situation.

system · August 29, 2023, 12:09pm

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Rust 1.71.1 pre-release testing announcements	5	979	November 2, 2023
Rust 1.74.0 pre-release testing announcements	7	935	March 4, 2024
Rust 1.77.0 pre-release testing announcements	5	756	June 16, 2024
Rust 1.71.0 pre-release testing announcements	13	1283	October 12, 2023
Rust 1.67.1 pre-release testing announcements	3	726	May 8, 2023

Rust 1.70.0 pre-release testing

Related topics