Open raybellwaves opened 4 years ago
A collection of thoughts.
We do this in other parts of Dask right?
Typically releases here only contain a couple of changes. We also squash on merge and add a version commit on release. The result of this is that the commit history is pretty readable.
A changelog would likely be copying the commit history, removing anything that wouldn't be interesting to users and maybe putting them into categories. If we feel this is valuable we should add these steps to the releasing docs on the README.
I personally check the releases section of GitHub for release notes and never look for CHANGELOG files. In Dask we typically do not make use of the releases feature in GitHub, where some rich text can be added to a git tag. I have considered suggesting use of this more widely in Dask, but the process we have now seems to work ok too.
I am also a fan of the release drafter GitHub action which gathers all merged PRs since the last release into a draft release. It can categorise or exclude PRs based on labels.
A CHANGELOG file will help people get an overview of what is new in new releases.
It doesn't have to be retrofitted it could start with what's new in 3.0.0