Rust has a very nice changelog, but the file is updated only for stable releases.
Unfortunately, it doesn't contain any information about upcoming changes in the beta versions of Rust. This is a problem, because:
I can't help testing new features in Rust betas, because I don't know what has changed.
Most users may hear about a new feature or an API only the day it's stabilized and final.
There is a lot going on with nightly features, in-progress RFCs, and thousands of issues in the GitHub issue tracker, but it's not clear which of these things are landing soon, and which are a far-future work-in-progress.
Would it be possible to update the RELEASES.md file sooner, when stabilization PRs are merged, or at least when the beta branch is cut?
I like this idea. I've personally caught a few regressions in upcoming stable releases when I adopt them at the stable prerelease testing phase; this is an indication that not enough people are using beta to catch those things, and having a changelog — and announcements thereof — would make it more inviting.
(Though, I suspect beta is inherently unattractive because it neither offers unstable features nor being itself the stable release you can reasonably assume everyone is using; choosing to use it requires being interested in supporting Rust development or in the specific features that are beta-only in the current cycle.)
We in the release team try to get a pull request for RELEASES.md fairly soon in the beta process, but we usually don't end up merging that until we're close to release. For example, here's 1.62:
If GitHub would let us pin a pull request, like they do for issues, I think we would use that here.
Personally I find it a great choice when devving, because it brings the improved compiler errors that 6 months quicker, assuming you have CI checking that you still build on stable. (Which you should have no matter what you use locally.) And it doesn't encourage you to muck with unstable features the way nightly does.
But as you said, that's in part because I'm "interested in supporting Rust development". It's certainly not the majority workflow.
There was some discussion on an issue for stabilization that I saw recently (I don't remember which issue unfortunately) that suggested there probably need to be more formal mechanisms for requesting feedback on specific unstable features on nightly.
This also came up in the discussion about GAT stabilization. A number of concerns weren't brought up until the stabilization PR was opened, which at least one person commented they found fairly concerning.
Those examples are both more focused on nightly but I think it applies just as well to beta features, though the things you'd be looking for on beta might be slightly different than on nightly.
I'm not sure what the best avenue for these kinds of announcements/requests would be. Having beta and nightly "release notes" like what the rust blog published for stable releases might be a good place to start (though I know that's potentially quite a lot of work, especially for nightly).
I notice that sometime the official Rust repro has a Relnotes branch. Maybe one could decide to always create that branch in the repro and merge any updates agressivly there.
I'm guessing that branch was accidental whenever it occurred -- whoever wrote the relnotes that time accidentally pushed their PR branch to rust-lang/rust instead of their own fork. I guess we could make that standard practice, but in reality it would be "aggressively merging updates" only because they're pushing changes for the actual PR.
I think the discussion here so far hasn't brought up anything new from that thread, just noting similar things, but unfortunately I don't think there are incredibly easy solutions here today. (Or ones that can be fully automated).
TWiR now has a "Call for Testing" section, which can include things that specifically are asking for people to help test (along with testing instructions).