Releasing a new version

Releasing a new version

This project adheres to the Semantic Versioning specification by Tom Preston-Werner.

The actual release (i.e. building the distributions and uploading to PyPI) are automated via GitHub actions. What currently needs to be done manually is updating the changelog, version files and the tag.

Process

• Log changes to:

  • CHANGES.rst

  Since writing adding the correct links is a bit tiresome, here is a little something to help you with it. It also covers the version bump (see next bullet point)

• Bump version:

  • telegram/_version.py
  • docs/source/conf.py
  • Replace all ocurrences of NEXT.VERSION by the correct version string in the docstrings
  • if the release includes a Bot API update, update README.rst
  • if the release drops a Python version, update README.rst and pyproject.tolm

• Commit & create a PR

• If all checks pass, squash-merge with the commit message:

  Bump version to v<VERSION> (#<PR-Number>)

• Create a tag for the new version:

  git tag -a v<VERSION>
  git push origin v<VERSION>

• Approve the deployment request for PyPI

• Wait for the GitHub action to finish uploding to PyPI and the GitHub releases page

• Adjust the new release:

  • Tag version: v<VERSION>
  • Release title: v<VERSION>
  • Description: <logs from CHANGES.rst>

• Trigger documentation rebuild:

• On Readthedocs dashboard trigger a build for stable release (you'd probably need to do it twice: check the git revision being built to make sure it's the right one).

• Close milestones for this version.

• Test in a clean virtualenv that pip install python-telegram-bot work with the new version.

• If the doc-fixes branch got merged, create a new one.

• Merge the dev-wiki into the production wiki

Public Announcements

Please use the following channels/groups to announce a new version release:

• @pythontelegrambotchannel
• @pythontelegrambotgroup (Channel posts are automatically forwarded to here)

Channel posts should be a bit more verbose than the plain release notes. E.g. they can

• list the (non-dev-team) authors, who contributed to the release, maybe even for each PR
• have a short, informative description of new/changed features