Preparing a pyproj release is a two-phase process.
In this phase, we want to ensure all the builds work on all platforms and methods of distribution for the next release.
The first step in this phase is to update the version number __version__
in __init__.py
to the next release <major>.<minor>.<patch>
. Then, add the rc
style posfix following the PEP-440 conventions.
The next step is to create a tag with the same name as the version just added. This can be done using the git command line or from https://github.com/pyproj4/pyproj/tags.
- Check the wheels built at https://github.com/pyproj4/pyproj using GitHub Actions.
- Create a draft PR at https://github.com/conda-forge/pyproj-feedstock and verify tests pass.
- Verify Debian builds were successful.
- Verify Fedora builds were successful.
- Verify the docs build successfully.
After the candidate has proven itself, it will be promoted to a final release.
Remove the rc
postfix from the the version number __version__
in __init__.py
.
The next step is to create a tag with the name <major>.<minor>.<patch>
. This can be done using the git command line or from https://github.com/pyproj4/pyproj/tags.
Next, go through the history and add release notes (see: automatically generated release notes). Make sure to acknowledge contributions made by others in the release.
The wheels are tested with each merge to main and uploaded to https://pypi.anaconda.org/scientific-python-nightly-wheels/simple in GitHub Actions. They are uploaded to pypi on pre-release and release in GitHub Actions.
A PR for pyproj
will be generated automatically after you push to pypi.
Verify all is correct on the PR at https://github.com/conda-forge/pyproj-feedstock.
On the gh-pages
branch, update the stable symlink to point to the next version.