Releasing¶
To release, first make sure that all CI tests are passing on main
.
Note that CuPy must be tested manually (it isn’t tested on CI). Use the script
./test_cupy.sh
on a machine with a CUDA GPU.
Once you are ready to release, create a PR with a release branch, so that you can verify that CI is passing. You must edit
array_api_compat/__init__.py
and update the version (the version is not computed from the tag because that would break vendorability). You should also edit
docs/changelog.md
with the changes for the release.
Once everything is ready, create a tag
git tag -a <version>
(note the tag names are not prefixed, for instance, the tag for version 1.5 is
just 1.5
)
and push it to GitHub
git push origin <version>
Check that the publish distributions
action on the tag build works. Note
that this action will run even if the other CI fails, so you must make sure
that CI is passing before tagging.
This does mean you can ignore CI failures, but ideally you should fix any
failures or update the *-xfails.txt
files before tagging, so that CI and the
cupy tests pass. Otherwise it will be hard to tell what things are breaking in
the future. It’s also a good idea to remove any xpasses from those files (but
be aware that some xfails are from flaky failures, so unless you know the
underlying issue has been fixed, an xpass test is probably still xfail).
If the publish action fails for some reason and didn’t upload the release to PyPI, you will need to delete the tag and try again.
After the PyPI package is published, the conda-forge bot should update the feedstock automatically.