search

freedomofpress / securedrop

GitHub repository for the SecureDrop whistleblower platform. Do not submit tips here!
https://securedrop.org/
Other
3.6k stars 685 forks source link

Standardize and automate changelog generation #5981

Open zenmonkeykstop opened 3 years ago

zenmonkeykstop commented 3 years ago

Description

Everyone in the RM role has their own personal process for generating the changelog for a given release, but all of them are more labor-intensive and error-prone than they should be. Having a single process that was at least partially automated would make the RM role more pleasant.

Feedback and suggestions are more than welcome!

rmol commented 3 years ago

I've been meaning to look into AutoPub. It doesn't yet support incremental updates of the changelog, but it could. It can also generate GitHub releases, and publish to PyPI, which are other tasks we haven't automated well.

Conventional commits are interesting, but sound like more work. An out-of-band approach like AutoPub's RELEASE.md seems more flexible.

cfm commented 2 years ago

I have to say I've really come to appreciate Conventional Commits. Even in solo projects, I've found the discipline it puts on Git history—for each commit to be atomic, self-contained, and self-documenting—to be worth the cognitive overhead and fiddly rebasing.

From there, there are a whole bunch of tools one can use to generate changelogs.

Outside of Conventional Commits, pbr may be also be of interest.

gonzalo-bulnes commented 2 years ago

I've somehow found the workflow of Conventional Commits impractical, but I do in practice commit in a way that's very close to that spirit, so maybe it's more about me finding a workflow that works for myself.

Even in solo projects, I've found the discipline it puts on Git history—for each commit to be atomic, self-contained, and self-documenting—to be worth the cognitive overhead and [fiddly?][frequent] rebasing.

:point_up: I relate completely to this (edited :upside_down_face:) quote!

gonzalo-bulnes commented 2 years ago

When it comes to creating change logs, though, I'm tend to favor aggressive prioritization and shorter change logs over commit-detailed ones. (I've rarely seen people taking the time to read through longer change logs, so I prefer making as sure as possible that the main takeaways are easy to ingest. YMMV)

I'd love us to play with some of the options proposed in this thread!