-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Making a new Release
- Create the changelog, bump the version number, and submit a PR for the release
- Verify the docs build properly and the changelog appears properly formatted (2 approvals required)
- Check if there are open PRs that should be merged for the next release (squash & merge and rerun the changelog script)
- Remove all objects/methods that are deprecated with a decorator (e.g.
@deprecated(until="v0.6.0" ...)
To generate a changelog for the next release, use scripts/dev_changelog.py under the root of the repository. You will need to generate a GitHub Personal Access Token (PAT) to use GitHub's API in the python script. You can do so (when logged in) here https://github.com/settings/tokens.
When you're ready with your PAT, ensure your local repo is up to date with upstream and run from the root of the project:
python dev_changelog.py [OPTIONS] TOKEN PRIOR TAG [ADDITIONAL]...
python scripts/dev_changelog.py -o /path/to/file.rst <Your-GitHub-PAT> vA.C.D HEAD
Since the script cannot interpret from the TAG argument (which is HEAD in this example) the name the version of the release, you'll have to edit the internal heading section manually.
To avoid this manual intervention, use git tag vX.Y.Z HEAD to locally tag for the upcoming release. For example:
python scripts/dev_changelog.py <Your-GitHub-PAT> v0.5.0 v0.6.0
Assuming the v0.6.0 tag exists, this will automatically generate a changelog with the appropriate name and place it in the appropriate directory (docs/source/changelog/). Make any necessary adjustments manually via the generated rst file or by editing the GitHub PR that needs editing and rerunning the script.
With the new commit in place, stage your changes and make a PR. Verify the changelog appears as expected in RTD/sphinx before creating the release!
NEVER PUSH MANUALLY TO PYPI: There are automatic actions which does that job for you as well as other. So creating a Release in Github After checking everything else would simply work out of the box.
The process for creating a new release is documented here. For regular releases, increment the minor (second decimal) and reset the patch (third decimal) (e.g. X.1.Z->vX.2.0) and for bugfixes, only increment the third (e.g. vX.Y.4->vX.Y.5). The release title is the same as the tag name. You don't need to create a tag from the command line as one will automatically be created for the release.
Run git checkout <tag> to switch to the tag you created when the release was created. Then run poetry publish --build to publish to PyPI. Finally, upload the .tar.gz file generated to GitHub Release Assets. Only when the automatic fail to do it.
Note: You don't need to publish it manually it is done automatically. This documented to as a backup if that action fail.
As long as we have an ongoing discussion about our stable branch, the default version of our documentation at https://docs.manim.community has to be changed to the latest release at https://readthedocs.org/dashboard/manimce/advanced/
Docker images for new releases are built automatically, no manual intervention required. Should it, for some other reason, be necessary to deploy a new tagged image, then this can be done by running docker build -t manimcommunity/manim:v1.7.42 -f docker/Dockerfile . from the repository root, and then running docker push. (@behackl can grant access to the docker hub organization and repository.)
- Prepare release announcement text.
- Post release announcement on reddit
- Post release announcement on Twitter
- Post release announcement on #announcements channel in discord