Numba Release Process
The goal of the Numba release process – from a high level perspective – is to publish source and binary artifacts that correspond to a given version number. This usually involves a sequence of individual tasks that must be performed in the correct order and with diligence. Numba and llvmlite are commonly released in lockstep since there is usually a one-to-one mapping between a Numba version and a corresponding llvmlite version.
This section contains various notes and templates that can be used to create a Numba release checklist on the Numba Github issue tracker. This is an aid for the maintainers during the release process and helps to ensure that all tasks are completed in the correct order and that no tasks are accidentally omitted.
If new or additional items do appear during release, please do remember to add them to the checklist templates. Also note that the release process itself is always a work in progress. This means that some of the information here may be outdated. If you notice this please do remember to submit a pull-request to update this document.
All release checklists are available as Gitub issue templates. To create a new release checklist simply open a new issue and select the correct template.
Primary Release Candidate Checklist
This is for the first/primary release candidate for minor release i.e. the first release of every series. It is special, because during this release, the release branch will have to be created. Release candidate indexing begins at 1.
## Numba X.Y.Z
* [ ] Merge to main.
- [ ] "remaining Pull-Requests from milestone".
* [ ] Check Numba's version support table documentation. Update via PR if
needed.
* [ ] Review deprecation schedule and notices. Make PRs if need be.
* [ ] Merge change log changes.
- [ ] "PR with changelog entries".
* [ ] Create X.Y release branch.
* [ ] Create PR against the release branch to make `numba/testing/main.py`
to refer to `origin/releaseX.Y` instead of `origin/main`.
* [ ] Dependency version pinning on release branch
* [ ] Pin llvmlite to `>=0.A.0rc1,<0.A+1.0`.
* [ ] Pin NumPy if needed
* [ ] Pin TBB if needed
* [ ] Run the HEAD of the release branch through the build farm and confirm:
* [ ] Build farm CPU testing has passed.
* [ ] Build farm CUDA testing has passed.
* [ ] Build farm wheel testing has passed.
* [ ] Annotated tag `X.Y.Zrc1` on release branch (no `v` prefix).
* [ ] Build and upload conda packages on buildfarm (check "upload").
* [ ] Build wheels and sdist on the buildfarm (check "upload").
* [ ] Verify packages uploaded to Anaconda Cloud and move to `numba/label/main`.
* [ ] Upload wheels and sdist to PyPI (upload from `ci_artifacts`).
* [ ] Verify wheels for all platforms arrived on PyPi.
* [ ] Initialize and verify ReadTheDocs build.
* [ ] Post announcement to discourse group and ping the release testers group
using `@RC_Testers`.
* [ ] Post link to Twitter.
### Post Release:
* [ ] Clean up `ci_artifacts` by moving files to sub-directories
* [ ] Tag `X.Y+1.0dev0` to start new development cycle on `main`.
* [ ] Update llvmlite dependency via PR to `main`, PR includes version updates
to:
* [ ] `setup.py`
* [ ] `numba/__init__.py`
* [ ] `docs/environment.yml`
* [ ] `buildscripts/incremental/setup_conda_environment.sh`
* [ ] `buildscripts/incremental/setup_conda_environment.cmd`
* [ ] `buildscripts/condarecipe.local/meta.yaml`
* [ ] Update release checklist template with any additional bullet points that
may have arisen during the release.
* [ ] Close milestone (and then close this release issue).
Subsequent Release Candidates, Final Releases and Patch Releases
Releases subsequent to the first release in a series usually involves a series of cherry-picks, the recipe is therefore slightly different.
## numba X.Y.Z
* [ ] Cherry-pick items from the X.Y.Z milestone into a PR.
* [ ] Update the "version support table" in the documentation with the final
release date (FINAL ONLY).
* [ ] Make, approve and merge a PR against the `main` branch.
* [ ] Create a cherry-pick from the merge and include in the cherry-pick-PR
for the `releaseX.Y` branch.
* [ ] Check if any dependency pinnings need an update (e.g. NumPy)
* [ ] Approve change log modifications and cherry-pick.
* [ ] Merge change log modifications and cherry-picks to X.Y release branch.
* [ ] https://github.com/numba/numba/pull/XXXX
* [ ] Review, merge and check execution of release notebook. (FINAL ONLY)
* [ ] Run the HEAD of the release branch through the build farm and confirm:
* [ ] Build farm CPU testing has passed.
* [ ] Build farm CUDA testing has passed
* [ ] Build farm wheel testing has passed
* [ ] Annotated tag X.Y.Z on release branch (no `v` prefix).
* [ ] Build and upload conda packages on buildfarm (check `upload`).
* [ ] Build wheels and sdist on the buildfarm (check "upload").
* [ ] Verify packages uploaded to Anaconda Cloud and move to
`numba/label/main`.
* [ ] Upload wheels and sdist to PyPI (upload from `ci_artifacts`).
* [ ] Verify wheels for all platforms arrived on PyPi.
* [ ] Verify ReadTheDocs build.
* [ ] Post link to Twitter.
* [ ] Post announcement to discourse group and ping the release testers group
using `@RC_Testers` (RC ONLY).
* [ ] Post link to python-announce-list@python.org.
### Post release
* [ ] Snapshot Build Farm config
* [ ] Clean up `ci_artifacts` by moving files to subdirectories
* [ ] Update release checklist template with any additional bullet points that
may have arisen during the release.
* [ ] Ping Anaconda Distro team to trigger a build for `defaults` (FINAL ONLY).
* [ ] Create a release on Github at https://github.com/numba/numba/releases (FINAL ONLY).
* [ ] Close milestone (and then close this release issue).