Enable Release 5.2.0

[aaronayres35]

Target date:

Release Candidate by YYYY-MM-DD

Release by YYYY-MM-DD

Release candidate

• [x] Verify that all relevant PRs have been merged to master.
• [x] Create a PR against master to bump version number, merge that PR (#831)
• [x] From the commit just before bumping the version, create a new branch maint/<release version number>
• [x] Update changelog and open PR targeting a new maint/<release version number> branch (#832)
• [x] Update ci-src-requirements.txt if needed
• [x] Check MANIFEST and requirements are still up to date. (#833)
• [x] Update version in setup.py for the prerelease, open 2 PRs against maint/<release version number>
  • [x] Create a new branch from maint/<release version number>: git checkout maint/<release version number>; git pull; git checkout -b call-it-anything-you-like
  • [x] Set PRERELEASE to "rc1" and IS_RELEASED to true, commit, e.g. git commit -m "Set IS_RELEASED to true for prerelease <release version number>rc1"
  • [x] Open and merge a PR against maint/<release version number> (~#834~ #837)
  • [x] Create a new branch from maint/<release version number>, Flip IS_RELEASED back to false, commit. (~#835~ #838)
  • [x] Open and merge another PR against maint/<release version number>
• [x] Tag (annotated!) the release candidate on the commit where IS_RELEASED is set to true, e.g. git tag -a -m "Release candidate <release version number>rc1" <release version number>rc1 <commit-hash>
• [x] Push the tag to GitHub
• [x] Upload to PyPI
  • git checkout <tag>, git clean -ffxd, python setup.py sdist, twine check dist/<...>.tar.gz, twine upload dist/<...>.tar.gz
• [x] Announcement for the release candidate

Release blockers

• [ ] ~#828~

Pre-release

• [x] Backport PRs that have been merged to master to the maintenance branch. Use the "need backport ..." tag if there is one (but don't rely 100% on it)
• [x] Verify that no other open issue needs to be addressed before the release.
• [x] Test against other ETS packages and other ETS-using projects
• [x] Check MANIFEST, requirements, changelog are still up to date.
• [x] Test building the documentation

Release

• [x] Create branch release/<release version number> from maint/<release version number> branch.
  • [x] Set release to <release version number>, and set IS_RELEASED is true; commit
  • [x] Install from source distribution and run tests again
  • [x] Open a PR against maint/<release version number> with this being the last commit so that CI is built on the release commit
  • [x] Once CI is done building merge PR (#855)
  • [x] Bump the micro version number i.e. <release version number + 0.0.1> and set IS_RELEASED to false; commit.
  • [x] Open and then merge a separate PR against maint/<release version number> (#856)
• [x] From the commit at which IS_RELEASED is true and version is <release version number>, tag (annotated!) git tag -a -m "Release <release version number>" <release version number>
• [x] Push the tag git push origin <release version number>
• [x] Make PR targeting gh-pages branch: Generate documentation and copy the content to the branch. Verify that the resulting index.html looks good. (#857)
• [x] Upload to PyPI
• [x] Test the PyPI package

Post-release

• [x] Package update for enthought/free repository (for EDM)
• [x] Backport release note and change log to master, and possibly maint/<release version number> branch. (#859)
• [x] Update GitHub Release pages https://github.com/enthought/enable/releases
• [x] Announcement (e.g. Google Group)

[aaronayres35]

closing as all tasks have been completed