On your release-candidate branch, update the CHANGELOG.
sh
gedit CHANGELOG.rst
Follow the style of the existing CHANGELOG entries to add a new entry for your release.
Use as many of the categories (Added, Changed, Deprecated, Removed, Fixed, Security) as necessary.
List all non-trivial changes, following the guidance of [Keep a Changelog].
If you're not sure what has changed, consult the [list of closed pull requests](https://github.com/rochefort-lab/fissa/pulls?q=is%3Apr+is%3Aclosed+sort%3Aupdated-desc), check which have closed recently and whether they are worth including in the CHANGELOG.
If you have nothing to list in the CHANGELOG, you should seriously question whether it is a good idea to create a new release!
Usually, previous pull requests which added noteworthy changes have also made changes to the CHANGELOG under the `Unreleased` section at the top, in which case you can move them down into your new release.
Your CHANGELOG entry should begin like so:
Version `M.N.P <https://github.com/rochefort-lab/fissa/tree/M.N.P>`__
---------------------------------------------------------------------
Release date: YYYY-MM-DD.
`Full commit changelog <https://github.com/rochefort-lab/fissa/compare/A.B.C...M.N.P>`__.
Where `M.N.P` is the new release, `A.B.C < M.N.P` is the previous ancestor to the new release, and `YYYY-MM-DD` is today's date.
The Full Changelog link will use the release tags on github to automatically generate a comparison.
The changes you list should be grouped into categories: Added, Changed, Deprecated, Removed, Fixed, Security.
See the description at the top of the CHANGELOG for more details.
For each category which appears in the Changelog of the new release, make sure to include an rST anchor declaration, such as the example below.
This tells sphinx what anchor to use for the subheading (in this case Fixed), which appears many times within the changelog document.
.. _vM.N.P Fixed:
Fixed
~~~~~
- Details of bug which was fixed.
(`1 <https://github.com/rochefort-lab/fissa/pull/1>`__)
For each change, the pull request which implemented that change in the master branch should also be linked to.
Note that the CHANGELOG should not contain an "Unreleased" section on the release-candidate branch.
Once you are done, add and commit your addition to the CHANGELOG.
sh
git add CHANGELOG.rst
git commit -m "DOC: Add $vMNP to CHANGELOG"