New Changelog formatting

[blyxyas]

[Related to this Zulip Meeting]

Grouping issues

This issue is a discussion around changing the changelog's formatting. Several solutions came out in the 2023-05-30 meeting, this issue discusses the last one (the conclusive one).

The conclusion that we reached on this meeting around the changelog is that we should group all small fixes (usually fixing false-positives and very small suggestion changes), that the user will have to click on. This can be done using the <details> and <summary> tags.

(The person making the changelog will decide what is a small change)

We would keep the current sections, and add a new one.
(Note that it is tempting using the Others section to group all small commits, but sometimes, changes that cannot be categorized in any of the other categories are significant. So we'll have to create a new section)

### New Lints
### Moves and Deprecations
### Enhancements
### False Positive Fixes
### Suggestion Fixes/Improvements
### ICE Fixes
### Documentation Improvements
### Others

<details><summary><h3>Minor fixes</h3></summary>
</details>

Minor fixes

• Someone fixed a typo yay :D #100000

Note the double space between ### Others and <details>. And the space between <details>, the content, and the final </details> (Github is pretty picky when rendering Markdown files that use HTML, but there isn't any other way to create dropdowns in Markdown)

---

The PR range

We would also replace the commit range (which is not very significant, as a single PR can have many commits) with a new merged PRs range.

The filter to use here would be something like this:

is:pr is:closed merged:<last release, YYYY-MM-DD>..<this release> base:master sort:merged-desc 

We could display it raw as a range:
#10669..#10841

(This approach doesn't make much sense, as PRs aren't sequential in any way)

Or maybe just provide a link to view it in Github

View 80 PRs merged since 1.69

---

Joining these 2 concepts would give us a much more legible changelog.

cc @xFrednet

[blyxyas]

@rustbot label +P-medium +S-needs-discussion

[xFrednet]

Hey @blyxyas, thank you for creating the issue. I really like the PR range and will switch to it in the next changelog.

---

For the second part, about minor changes, you wrote:

The conclusion that we reached on this meeting around the changelog is that we should group all small fixes (usually fixing false-positives and very small suggestion changes), that the user will have to click on. This can be done using the <details> and <summary> tags.

I had a different understanding, that minor changes can be dropped completely from the changelog. Having a condensed version was suggested, but there was no real answer, if many people would be looking in into the minor changes. (I usually don't). I guess we'll see if someone requests more details on the next changelog.

Now, I'm also biased to having a shorter changelog format, than just changing it. This has two reasons:

1. Most of the time needed to write the changelog is spent on bringing all PR entries into a (kind of) uniform style. Dropping smaller changes would save time, but if we include them in a condensed section, they still need to be reviewed and often reformulated.

   In this regard, it might be worth mentioning, that I'm a relatively slow reader and writer. That, makes me biased towards having to write less ^^

2. The changelog file is quite large by now. My fan laptop fan turns on when I just open the file ^^. By reducing the format length, I'm hoping to slow down the growth. This is of course not the main reason, and there are other options to deal with it. However, slowing down the growth would be a nice benefit.

[blyxyas]

I agree with both your points. Remove them if you want ^w^

[xFrednet]

Naw, I'll keep em :D

We can see, if we get any feedback from others, when we try the new format in the next changelog. That'll be next release. I'll assign myself to this issue in the meantime, to find it again later. Thank you for documenting this!!!

@rustbot claim

[blyxyas]

Sooo... You just pulled an Uno reverse card just to work more?
What a chad 👏

[xFrednet]

What? o.O

Ohhh, you were suggesting updating the old changelogs as well? Sorry, I totally misunderstood the first sentence 😅. But if we mainly remove sections, it should be doable with a script right? xD

[blyxyas]

Nop, I wasn't suggesting updating the old changelogs as well, I just agreed that, if you're a slow writer, we should minimize time spent writing.

[blyxyas]

@xFrednet Should old commit ranges be converted (possibly by a script) to the new PR ranges? I find them too useful not to use.

[xFrednet]

Hey @blyxyas, You can convert the old rages if you like. :D One thing, worth mentioning, is that the commit ranges and dates don't fully align with the releases. Instead, they're determined by the time a sync was done into the rust repo. It should (hopefully) be sufficient to just look up the date of these commits and use that for the date filter :)