search

spacepy / dbprocessing

Automated processing controller for heliophysics data
5 stars 4 forks source link

Set up release notes #28

Closed jtniehof closed 3 years ago

jtniehof commented 3 years ago

We should have a basic release notes setup (sort of like https://numpy.org/doc/stable/release.html that can also be incorporated into the github release page, again e.g. https://github.com/numpy/numpy/releases .) The PR template should also be updated to reference updating the release notes instead of CHANGELOG.

Closure condition

This issue should be closed when: we have a basic release notes included in the repository, including directions for including in the release (i.e. stub out how-to-release documentation), and the PR template updated to reference the release notes instead of CHANGELOG.

jtniehof commented 3 years ago

Numpy includes a list of merged PRs: https://numpy.org/doc/stable/release/1.17.5-notes.html#pull-requests-merged This might be fun although tricky (the PR that includes a change should include the update that links that PR from the release notes? Does numpy have a script that does this for them?)

Maybe also include the issues closed.

What this does is allows a very fine-grained presentation of what happened without having to copy/paste all history into the PR.

jtniehof commented 3 years ago

It looks like numpy uses a changelog that gets processed into the release notes using towncrier. The changelog is made partially from github using a custom numpy tool that doesn't look too huge so it's probably worth just reimplementing for our purposes with those ideas.

I think a high-level summary + list of PRs merged + list of issues closed will probably do the trick for us. It doesn't look like the numpy changelog is as detailed as, say, the SpacePy changelog.

jtniehof commented 3 years ago

Sample of what the auto-generated changelog for release notes could look like...happy to have formatting/content comments. (E.g. do we want date closed?)

changelog

jtniehof commented 3 years ago

My intention here is to have enough information that if Github disappeared, we wouldn't have a full archive of discussion but there'd be enough to have some idea of how commits relate to the intention of pull requests and issues they address. (Although with the GitHub API it would be possible to pull pretty close to a full record, if we wanted an exhaustive changelog somewhere...at least we could include body instead of just title of PR/issue.)