Rust 1.82.0 released [LWN.net]

Version 1.82.0 of the Rust language has been released. There are a lot of new features this time, including a cargo info command, tier-1 support for 64-bit Apple Arm systems, a new native syntax (&raw) to create raw pointers, changes to unsafe extern, unsafe attributes, standardized rules around the handling of floating-point not-a-number values, and more.

to post comments

Vastly improved release notes

Posted Oct 18, 2024 6:17 UTC (Fri) by riking (subscriber, #95706) [Link] (4 responses)

I believe this is probably the first Rust release with the new release notes process, where the authors of a "release notes worthy" merge request are asked in a new Github issue to write the release notes for their feature, and if they don't respond in time then the Rust project team in charge of that area writes the release notes instead.

Vastly improved release notes

Posted Oct 18, 2024 12:54 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (3 responses)

Hmm…why not have release notes just come in with the original change? I know "release notes from commit log" is a terrible idea (how do you update/remove release notes in this case?), but we started using "drop a file into a directory with your release notes" and then part of the release process is just going and collating everything in that directory. This allows them to be updated, reverted, etc. just like code prior to release. It also means that if you backport the changes, you get a release note item along with it.

Vastly improved release notes

Posted Oct 18, 2024 13:11 UTC (Fri) by raven667 (subscriber, #5198) [Link] (1 responses)

meta> I'm not a Rustician but had a thought which writing helps form.

That sounds like a good process and maybe after they get some practice with many developers contributing to the release notes they can delegate out and organize this way, but they probably weren't ready for a new "release notes document is part of the feature branch" policy all at once. Or maybe they just didn't think of it at the time. Adopting process can be hard and people need time to adjust in small steps

Vastly improved release notes

Posted Oct 18, 2024 13:44 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Good point…I'll bring it up on IRLO.

Vastly improved release notes

Posted Oct 18, 2024 16:50 UTC (Fri) by atnot (guest, #124910) [Link]

Agreed, this is a good idea in general. However it comes with the usual caveats of being made to do stuff up front, and may be outdated by the time of the release or part of a larger feature that doesn't need to be explained multiple times.

The best way I've seen is (as it always seems to be) the way Bevy does this: The pull request template has a section for draft release notes and migration instructions for the author to fill in. When the release is about to be cut, all of those sections are collected into a big document to form the draft release notes, and the authors of each respective change are tagged in it for their input. The release notes are then collaboratively edited, with or without the input of the relevant users, up until the release is ready. Same for the migration guide. This has worked extremely well from what I can tell, although it does need someone willing to steward the process.