Fissa

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"

Change hard links within the documentation to point to the release tag instead of the master branch and latest release.

sh
for MODE in "" "archive/" "blob/" "tree/";
do
find . \( -type d -name .git -prune -o -name HOWTO_RELEASE.* -prune \) -o -type f -print0 | xargs -0 sed -i "s;rochefort-lab/fissa/${MODE}master;rochefort-lab/fissa/${MODE}$MNP;g"
done
for MODE in latest stable;
do
find . \( -type d -name .git -prune -o -name HOWTO_RELEASE.* -prune \) -o -type f -print0 | xargs -0 sed -i "s;fissa.readthedocs.io/en/$MODE;fissa.readthedocs.io/en/$MNP;g"
done


Commit these changes.
sh
git add -u
git commit -m "DOC: Freeze documentation links to point to $vMNP release"

In `__meta__.py`, update the version number as required (see above and the [Semantic Versioning standard][semver] for details).

sh
gedit fissa/__meta__.py
edit file and save changes
git add fissa/__meta__.py
git commit -m "REL: Version $MNP"

Create your release candidate branch whose name bears the format `rel_M.N.P`.

Merge all changes which should be included in your new release into the release candidate branch, `rel_M.N.P`.

However, if you are releasing a patch for a previous version (the current release is `M.(N+1).0`, or later), you should not merge master into `rel_M.N.P` as it will contain features or API changes not suitable for your patch release.
Instead, you should merge the relevant bug-fix branches directly into `rel_M.N.P`.
If the bug-fix branches you need have been deleted, you may have to [cherry-pick](https://git-scm.com/docs/git-cherry-pick) commits from master.
sh
git checkout "$vMNx"
git pull
git checkout -b "rel_$MNP"



3. Update metadata for your release

On your release-candidate branch, `rel_M.N.P`, update the metadata to reflect your new release.

Typically, your new release will contain everything currently in the bleeding-edge codebase from the master branch of the repository.
sh
git checkout master
git pull
git checkout -b "rel_$MNP"