Making freud Releases¶
Release Process¶
Documented below are the steps needed to make a new release of freud.
Create a release branch, numbered according to Sematic Versioning:
git checkout -b release/vX.Y.Z
Changelog¶
Review headings (Added, Changed, Fixed, Deprecated, Removed) and ensure consistent formatting.
Update the release version and release date from
next
tovX.Y.Z - YYYY-MM-DD
.
Submodules¶
Update git submodules (optional, but should be done regularly).
Bump version¶
Commit previous changes before running
bumpversion
.Use the bumpversion package to increase the version number and automatically generate a git tag:
bumpversion patch # for X.Y.Z
bumpversion minor # for X.Y
bumpversion major # for X
Push the release branch to the remote:
git push -u origin release/vX.Y.Z
Ensure that ReadTheDocs and continuous integration pass (you will need to manually enable the branch on ReadTheDocs’ web interface to test it). Then push the tag:
git push --tags
Automatic Builds¶
Pushing the tag will cause CircleCI to create a release for PyPI automatically (see automation in
.circleci/config.yml
). Make sure this succeeds – it takes a while to run.Create a pull request and merge the release branch into the
master
branch. Delete the release branch on ReadTheDocs’ web interface, since there is now a tagged version.The conda-forge autotick bot should discover that the PyPI source distribution has changed, and will create a pull request to the conda-forge feedstock. This pull request may take a few hours to appear. If other changes are needed in the conda-forge recipe (e.g. new dependencies), follow the conda-forge documentation to create a pull request from your own fork of the feedstock. Merge the pull request after all continuous integration passes to trigger release builds for conda-forge.
Release Announcement¶
Verify that ReadTheDocs, PyPI, and conda-forge have been updated to the newest version.
Send a release notification via the freud-users group. Follow the template of previous release notifications.