Split release notes file in two parts

[djc]

For a while now, it's been a pain that RELEASES.md no longer renders as HTML when browsing GitHub (because it's grown too large) -- discussion on Zulip. Split the file in two parts, using 1.56 (as the first release containing 2021 edition support) as the boundary -- the old file is now called RELEASES-old.md. RELEASES-old points to RELEASES.md at the top, while RELEASES.md now points to RELEASES-old.md at the bottom.

Alternatively, we could explicitly call -old something more like -pre-1.56, which has the advantage of being more clear up front but the disadvantage of having to move it when we next want to move the boundary.

As another alternative, we could split it up over more files (one per edition?) so that each file will be small enough to render even in the longer term. However, that would make it (slightly) harder to search all of them together.

There are different colors we could paint this particular bikeshed but this seems like a nice incremental improvement.

Fixes #101714.

[rustbot]

r? @Mark-Simulacrum

(rustbot has picked a reviewer for you, use r? to override)

[weihanglo]

Thanks for the MVP! However, this breaks old links everywhere on the internet. We should use our best effort to keep those links alive.

[djc]

It's a fair point, though I would argue those links are currently already broken, and this PR doesn't fix (most of) them.

[weihanglo]

Off the top of my head, probably have this in RELEASE.md for compatibility.

Version 1.69.0 (2023-04-20)
===========================

<a id="1.69.0-Language"></a>
<a id="1.69.0-Compiler"></a>
<a id="1.69.0-Libraries"></a>
<a id="1.69.0-Stabilized-APIs"></a>
<a id="1.69.0-Cargo"></a>
<a id="1.69.0-Rustdoc"></a>
<a id="1.69.0-Compatibility-Notes"></a>
<a id="1.69.0-Internal-Changes"></a>

Please read [the release note from some other fancy place](https://example.com).

And it could be a link to the Git tag.

[weihanglo]

Or just have all old links as <a> anchors right below this.

[weihanglo]

I mean this

For older releases, see [`RELEASES-old.md`](RELEASES-old.md).

GitHub cannot even render this diff comment properly for large blobs…

[est31]

This fixes the issue but it breaks all links to pre 1.56 release notes, and we also know it's not a permanent solution: eventually we'll have as much content in the new file and then we'll have to split again (admittedly, that's years out). Having one file per release is also not good IMO because I think many people prefer larger files over smaller ones. My proposal: make one file per edition, this size should be constant: one for edition 2015 and pre-1.0, one for edition 2018, one for edition 2020.

Or alternatively, move the edition 2020 stuff into RELEASES-2020.md, and keep everything else in the old file: the edition 2020 has the fewest releases so the least amount of links are broken (at least if you assume constant amount of links for each release which might not be true due to Rust's growth).

But of course, ideally github would improve their markdown rendering engine to e.g. use a rust based one that stays below timeout limits. Has github been contacted and asked if they can find a way to address the issue without breaking links? Then once edition 2023 comes, we can put the notes for that one into a new file and keep everything else in the old release notes file, keeping that one at a constant size.

[Mark-Simulacrum]

I'm going to go ahead and close this PR -- thanks for putting it up. For 1.70, we linked to the rendered copy on the git tag from the blog post, and all historical releases also have associated tags + rendered markdown attached I believe.

I've also posted #112257 which cuts the file down by ~9% without changing the rendering. It sounds like that's not enough for it to start rendering yet, so we may not merge it, but I think it's a better interim step than something like this which breaks links (as others have mentioned).

We've also reached out to GitHub (not sure if we did previously, but definitely have now) to ask about this issue and see what we can do there or learn about the particular limits we're hitting to guide a solution.

Thanks for doing this work!