Some improvements to the releasing docs

Author: asmeurer

docs/dev/releasing.md

@@ -1,7 +1,8 @@
 # Releasing
 
-To release, first note that CuPy must be tested manually (it isn't tested on
-CI). Use the script
+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
@@ -25,25 +26,34 @@ CHANGELOG.md
 
 with the changes for the release.
 
-Then create a tag
+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 works. Note that this action
-will run even if the other CI fails, so you must make sure that CI is passing
-*before* tagging.
+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, a xpass test is probably still xfail).
+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.