Skip to content
Joris Van den Bossche edited this page Feb 28, 2024 · 13 revisions

Checklist before starting a release:

  • All wheel building infrastructure up to date? (latest Python and GEOS version) Also on CircleCI for the Linux aarch64 wheels?
  • Check or update the copyright year on Line 15 in shapely/docs/conf.py
  • Update version and date-released fields in CITATION.cff
  • Add date to release notes (both in CHANGES.txt and /docs/release/2.x.rst), ensure the list is complete, and add acknowledgements (eg based on git shortlog -s 2.0.1..2.0.2)

Releasing:

  • Make an empty release commit: git commit --allow-empty -m 'RLS: 2.0.0'
  • Tag the commit using an annotated tag. git tag -a 2.0.0 -m "Version 2.0.0"
  • Push the RLS commit git push upstream main
  • Also push the tag! git push upstream --tags
  • Then the github worflow will create sdist/wheel, upload to PyPI, create a GitHub release, and attach the sdist
  • Manually update the GitHub release body text (with content from changelog)

Packaging:

  • update on conda-forge should be done automatically once the github release is made

  • PyPI is already done by workflow from GitHub actions

  • Manually download the aarch64 wheels from CircleCI and upload those to PyPI using twine:

    mkdir wheelhouse
    cd wheelhouse
    curl https://circleci.com/api/v1.1/project/github/shapely/shapely/latest/artifacts \
       | grep -o 'https://[^"]*' \
       | wget --input-file -
    twine upload *
    # twine upload * --repository shapely # if you configured .pypirc to use specific token for shapely
    

When branching for maintenance, we tag the next commit on main with the dev version of the future major release. For example, after branching for 2.0.x, we tag for 2.1 dev:

git tag 2.1.0.dev0 eeef37fcf398afeb6342d37b63037dc398fa1a5c
git push upstream --tags
Clone this wiki locally