Release Procedure

This is the maintainer note on how to Release. All versioning is in accordance to Semantic Versioning 2.0.0. This means older version would have a backport of bugs fixes.

  1. Check whether the test suite passes on the main branch.

  2. Revert any changes which seems to be not working, and check for the milestone if PR are merged accordingly.

  3. Check whether the Wheels Build, against the main branch works as expected.

  4. Clone the repository locally.

  5. Bump the version in manimpango/_version accordingly.

  6. Make a commit with the changes done, as Release v<version here>

  7. Create a tag, locally with

git tag -s v<version-number>

Note

Here, -s is used to sign the tag with gpg so that users can later verify it, and a tag shouldn’t be created with signing because Github shows it unverified.

Important

The message should include the changelog of the release. There is a github actions which will creates a draft release with the changelog. You can edit them and copy it to the tag you create.

  1. Push the tag to remote.

  2. Go to Github, and draft a new release with the same tag pushed. You can copy the same changelog you copied when you created the tag.

Important

You should actually “draft a new release” instead of just publishing a previously present draft release created by the Github Action. This is important so that the wheels build workflow triggers.

  1. Check whether the CI uploads the wheels and the .tar.gz file to PyPi.

  2. Finally, test the .tar.gz which was uploaded to PyPi, and install it in a new virtual environment.