[skip ci] Minor improvements to doc for release-version.sh

Author: mdbenito

CONTRIBUTING.md

@@ -674,10 +674,20 @@ Then, a new release can be created using the script
 part):
 
 ```shell
-build_scripts/release-version.sh v0.1.6
+build_scripts/release-version.sh 0.1.6
 ```
+This will:
 
-To find out how to use the script, pass the `-h` or `--help` flags:
+ - Pull latest remote version of develop (fast-forward only) from origin
+ - Create a branch `release/v0.1.6`
+ - Bump version number: 0.1.5.dev1234 ⟶   0.1.6
+ - Merge release branch into master locally and on origin
+ - Tag as `v0.1.6`
+ - Bump version number again to next development pre-release
+ - Merge release branch into develop locally and on origin
+ - Delete release branch
+
+For usage details, pass the `-h` or `--help` flags:
 
 ```shell
 build_scripts/release-version.sh --help
@@ -687,11 +697,10 @@ If running in interactive mode (without `-y|--yes`), the script will output a
 summary of pending changes and ask for confirmation before executing the
 actions.
 
-Once this is done, a tag will be created on the repository. You should then
-create a GitHub
+Once the script is done, you should then create a GitHub
 [release](https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository#creating-a-release)
-for that tag. That will a trigger a CI pipeline that will automatically create a
-package and publish it from CI to PyPI.
+for the tag that was created. That will a trigger a CI pipeline that will
+automatically create a package and publish it from CI to PyPI.
 
 ### Manual release process
 

build_scripts/release-version.sh

@@ -39,7 +39,7 @@ Usage:
     -r, --remote <remote>   The remote on which to release, default is origin
 
   Positional options:
-    VERSION_STR   Version to release, e.g. v0.1.2.
+    VERSION_STR   Version to release, e.g. 0.1.2 (tag will be v0.1.2)
                   If not specified, 'bumpversion' is used to determine release version number.
 
   Prerequisites: