-
Notifications
You must be signed in to change notification settings - Fork 5
Creating a release
A major release must be created for change sets that either break backwards compatibility in a significant manner or are otherwise representing a major overhaul of the library such as a significant change in available features or significant code base rewrites.
Minor releases are backwards compatible and introduce new features and fixes. Once a release due date has been established, the feature-freeze date should be communicated to all developers. Usually about 1 week prior to release.
A patch releases is a change that does not break backwards compatibility nor introduces new features, but only introduces bug fixes or other fixes related to the package structure. Any release that increments the third component of the semantic version is a patch release. A hotfix release is a patch release that is created directly from a previous release and is not part of the regular version history on the default branch.
A patch release should be created to release changes that fix critical issues such as security related issues, issues that are blocking for users including, but not limited to, any issues that prevent installation, may lead to data corruption, break workflows, are related to a major regression, or are otherwise time-sensitive.
TO DO: Add 'CITATION.cff' file once coxeter paper is published.
TO DO: Add 'Contributors.yaml' file.
bumpversion is configured to not make a tag. GitHub's release tool will make the tag when you click "Publish Release."
- Create release branch (see instructions below).
- Finalize changelog entries (review commits to ensure completeness).
- Update version and release date in changelog.
- Update pre-commit hooks by running
pre-commit autoupdate. - Draft release on GitHub (put changelog in description, see past releases for format). Click "Save draft", not "Publish release" for now.
- Merge master into release branch.
- Bump version with
bumpversion [patch|minor|major]command. - Push release branch.
- Apply any last minute changes if needed.
- Make PR for release and review and accept it after all tests pass.
- Publish release on GitHub from
master(which should be pointing to the commit from the merged PR). - Check that the PyPI package has been updated.
- Update conda-forge feedstock. A pull request will be automatically created by the conda-forge autotick bot within a few hours. However, the recipe must be manually updated if dependencies have changed since the last release.
- Check that the conda packages have been updated.