How to make a feature release

This page outlines the procedure for making a feature release (for example, releasing Traits 6.2.0).

Notes

This differs in some details from the official ETS release guidelines.
We consistently use squash-and-merge when merging Traits PRs. All references to merging PRs below assume squash-and-merge.

Review outstanding issues and outstanding PRs; decide which PRs and which issues need to be resolved prior to the release.
Resolve those issues and PRs appropriately!
Make sure the changelog is up to date. It should include:
- A release date!
- A list of contributors: the git shortlog command is useful here. For example:
```
$ git shortlog 6.1.1..HEAD -ns --group=author --group=trailer:co-authored-by
```

At this point, all the hard work should be done: the master branch should contain all the content that's destined for the release.

Double check that the changelog is up-to-date, possibly minus the correct release date.
Double check that your local checkout is up-to-date with respect to the GitHub remote, and that you're on the latest commit on master.
Make a PR against the master branch to bump the version number in setup.py for continued development towards the next feature release. Note that IS_RELEASED will be False in the master branch, and it should stay False. Typically, only the value for MINOR will need to be changed. Merge that PR (after the usual review and approval).
From the commit immediately preceding the version number bump in the PR in the previous step, create a new branch with name of the form maint/<major.minor>. We'll use this branch for the release and subsequent bugfix releases. Note that any branch name starting with maint/ automatically has branch protections applied, so all changes to the release branch will need to go through a PR.
Check that the sdist and wheels for the release have been successfully uploaded to PyPI.