Clippy release process: Including our changelog in the upstream release announcement

[Manishearth]

Currently Clippy maintains a changelog, however it only contains stuff for the current stable release.

We should also maintain one for the beta branch, and work with the release team each release to add things to the release blog post and link to the changelog, IMO.

Thoughts? @phansch @oli-obk

cc @Centril from the release team side

[Manishearth]

We could also encourage each nontrivial PR that lands to have a changelog entry in the PR body? Making changelog generation easy.

[Manishearth]

#3956

[Centril]

cc @rust-lang/release

I think we can, trivially, as a start, link to the clippy changelog in each new release.

I've included this in T-release's agenda for next week.

[Manishearth]

That sounds easy enough. Be sure to ping us so we can update it first 😄

Hopefully we'll always have an up to date beta changelong

[phansch]

Sounds good!

Hopefully we'll always have an up to date beta changelog

The main reason I didn't include the beta changelog initially was indeed the extra work required to maintain it, but I think we can do that.
I'm not clear on when we should update the beta changelog, though. Is it enough to update it after every stable release?

[Manishearth]

I mean, now that I wrote the first beta changelog, it's the same amount of work -- instead of writing the release changelog at release time, write the beta changelog 😄

I'm not clear on when we should update the beta changelog, though. Is it enough to update it after every stable release?

Yep. Before the stable release update the changelog so that the "beta" marker is removed. After the release, add a beta section. (Can be done simultaneously if you know what the beta cutoff is, which will usually be the case)

[Manishearth]

What do y'all think about editing a changelog line into each non-refactor PR that lands?

Basically, before you approve a PR, make sure you add a changelog: blah blah line to the PR body (if you're a reviewer and can't edit PR bodies, lmk).

That way changelog generation becomes super easy.

[flip1995]

Basically, before you approve a PR, make sure you add a changelog: blah blah line to the PR body

Yeah that sounds good. Forgetting this may be the main problem. Is there a way we can check this automatically? Maybe implement a require_changelog option for this into bors?

[Manishearth]

We don't want this on all PRs, but yeah, a check like this is easy to add to homu.

[Manishearth]

(we can always changelog: none for those)

[pietroalbini]

Hmm, I'd prefer to avoid too many repo-specifing things being added to homu. Maybe this can be done in the travis build itself (get the PR number, call the API to fetch the message, and fail if it's not present)?

To avoid people forgetting it exists wasting CI time, a PR template could be used that adds changelog: none to the default body.

[Manishearth]

Kinda wanted the fast feedback cycle of knowing immeeiately as you r+ so that the reviewer can add one (as opposed to the PR author)

Iffy on adding it to the template with a default none since people may not notice it and leave it to be none

[flip1995]

Maybe this can be done in the travis build itself

Sadly that's not possible, since to use the GitHub API you need an API token. For this you need secrets in Travis. But Secrets aren't accessible in PRs from forks. See #4031

[cuviper]

The bors CI builds are on a direct branch though, not a forked repo. I believe we do use secrets for stuff like AWS caching already.

[XAMPPRocky]

If the clippy team was okay with it, we could merge or copy Clippy's CHANGELOG to be another section in the Rust RELEASES.md? It would not add any significant time to my work. I already wrote a tool for the generating the release notes and could add clippy to it.

The relnotes tool I wrote does something similar to what is being suggested. It first finds the start and end date of the six weeks between the last release and the release before it (aka what's in beta). It uses these dates to get every PR merged to a repo (In this case rust-lang/rust & rust-lang/cargo) in that time. It then compiles these PRs into a Markdown document with a list of the titles of each PR with a respective link, seperated by category (lang, compiler, etc.). It does this using GitHub's labels (e.g. T-compiler -> compiler related PR). We also use the relnotes label to mark that the writer of the release notes should always include this PR in the draft to be submitted.

[Manishearth]

We do this already