Making a feature release

This page outlines steps for making a feature release of Envisage. Feature releases are usually made directly from the HEAD of the main branch.

Prior to release

In the weeks and days prior to the release:

Make a release milestone on GitHub, if none already exists.
Review open issues and PRs and identity the issues and PRs that should be a part of the release; add them to the milestone.
Address issues and deal with PRs as appropriate.
Make a PR to update the version number and changelog. This will usually be the last PR merged prior to release.

Before you tag the release, check that:

Your local checkout is clean.
You're on the HEAD of the main branch, and up-to-date with the most recent GitHub changes.
The changelog file CHANGES.rst is up to date, including all recently-merged (and not-so-recently-merged) PRs.
The version number in pyproject.toml matches the intended release version.
The package builds cleanly with python -m build, the generated source distribution and wheel pass a twine check --strict check.
The package can be installed into a venv, and all tests pass.

Consider also testing downstream packages against the candidate release commit.

Use an annotated tag to tag the release: for example with git tag -a 7.1.0. This should open an editor window for the tag message. Edit the tag message to start with a single line in the form "Envisage 7.1.0" and continue with the release notes.
Push the tag to GitHub with git push --tags
Edit the GitHub release on the Releases page. The release should include the release notes.
Publish the release on GitHub. This should automatically trigger wheel and sdist builds and uploads to PyPI.
Check that the PyPI page is updated.
Open an issue at https://github.com/enthought/buildsystem to request an egg build.
Announce the release on appropriate channels.

Run the "Test the documentation build" workflow on the released tag. This will create an artifact containing the built docs. If using gh, you can use something like: gh workflow run test-doc-build.yml --ref 7.1.0
Check out the gh-pages branch.
Move existing docs (for the previous release) into a new subdirectory with name of the form <major>.<minor> (for example, 7.0)
Download the documentation artifact: gh run download -n documentation
Copy contents of the unpacked html directory to top level.
Check that the documentation looks and works as expected (including the search functionality). You can do this by starting a local server with python -m http.server and navigating to localhost:8000.
Make a PR to update the documentation.