Rust 1.74.0 pre-release testing

announcements
1

The 1.74.0 pre-release is ready for testing. The release is scheduled for November 16. 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-11-13/index.html.

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

2 Likes
2

Are we ever going to address the "This blob took too long to generate" problem, or it going to be stuck in procrastination hell for the next three years?

My suggestion:

  • We create a new file named RELEASES_EDITION_2021.md, and copy-paste everything from 2021 onwards into that changelog.
  • Once 2024 arrives, we create a new file named RELEASES_EDITION_2024.md, and so on.
  • We add a link to these changelogs at the top of RELEASES.md.

That way we have a natural way to split files, and we don't break links to previous releases either.

8 Likes
3

Why not provide this link instead : 1.74.0 | Rust Changelogs

5 Likes
4

In short, because releases.rs isn't an official publication of the Rust project. It could be adopted given agreement between the team and the current operator, but that's not the case yet.

That's not completely true. "Deep" links to RELEASES.md#version-release-date would no longer link directly to the relevant heading. Though if the file completely stops ever rendering, the links are effectively broken anyway.

Unless you're suggesting to forever duplicate the contents between RELEASES and RELEASES_EDITION, which causes its own issues due to having to manually update and keep those separate files in sync.

5

A relatively simple approach to work around the problem would use the existing docs infrastructure:

4 Likes
6

I assume the OsStr(ing) encoded bytes stabilized APIs are a simple rename of the existing "os_str_bytes" apis?

7

I've created a PR with the approach I mentioned:

That's not completely true. "Deep" links to RELEASES.md#version-release-date would no longer link directly to the relevant heading. Though if the file completely stops ever rendering, the links are effectively broken anyway.

That might be more clear by looking at the PR, but my point is that the RELEASES.md file becomes a "legacy" file that stops being updated. So existing links are fine, and new updates go into RELEASES_XXXX_EDITION.md files.

2 Likes
8

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