-
Notifications
You must be signed in to change notification settings - Fork 365
Release checklist
Phil Elson edited this page Aug 1, 2017
·
4 revisions
A work-in-progress checklist of tasks for creating a release:
- Ensure @cartopy-devs are aware of a forthcoming release. Try to give at least a 2 week window for minor versions increments (note: versions follow
major.minor.patch
). - To define the scope of the release, update milestones and chase-up PRs which we want to see in the release.
- Update the what's new documentation with highlights and deprecations. An attempt to keep this up-to-date throughout the development process should be made, though inevitably things slip through the gap.
Once everything is in place:
- Cut a release branch for major or minor releases. Branch name should be
v{major}.{minor}.x
. - Increment the release on master. This should take the form of
v{new_major}.{new_minor}.dev1
. Place where version is important:setup.py, lib/cartopy/__init__.py, docs/source/_static/version_switch.js
. - Tag a release with these versions correctly set. A release candidate may be necessary for invasive changes - communicate this with cartopy-dev before the fact. (e.g.
git tag -a v0.12.0rc1 -m "v0.12.0rc1" && git push upstream --tag
) - Build the documentation for the tagged version. Ensure that your build is from a clean checkout, and doesn't have any configuration files etc. (cartopy.siteconfig). Add this built documentation to https://github.com/SciTools/scitools.org.uk. It will need to be uploaded once merged - @pelson has upload permission to scitools.org.uk.
TODO:
- Upload to pypi (https://github.com/SciTools/cartopy/issues/610#issuecomment-99170996)
- Notify mpl-devel
- Notify iris mailinglist
- Publicize in other ways (perhaps twitter, etc.)
- Update https://github.com/conda-forge/cartopy-feedstock to build the new tag.