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.

Pre-release checks

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.

Making the release

• 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.
• [TBD] Instructions for updating the documentation build.
• Open an issue at https://github.com/enthought/buildsystem to request an egg build.
• Announce the release on appropriate channels.