Update documentation

docs/src/development.md

@@ -482,12 +482,12 @@ python release.py --help
 - Create a **minor** release if the next release contains new or changed functionality.
 - Create a **patch** release if the next release contains only bug fixes.
 
-If you want to test the release (for example, deploy it to a test environment, or roll out a release to early adopters), it's possible to create a **release candidate** for a major, minor, or patch release.
-
-If the release type is major, minor, or patch, update the [version overview](versioning.md#version-overview).
+Before creating a release, it first needs to be tested as a **release candidate** for a major, minor, or patch release.
+Aside from testing by automatic pipeline it can for example be deployed to a test environment, or rolled out to early adopters.
+Before finalizing the release candidate, make sure to update the [version overview](versioning.md#version-overview).
 
 ```{important}
-To determine whether a release is major, minor, or patch, compare the changes to the [previous most recent release](changelog.md), excluding release candidates.
+To determine whether a release is major, minor, or patch, compare the changes to the [previous most recent release](changelog.md).
 ```
 
 ### Determine the version bump
@@ -496,32 +496,34 @@ Having decided on the release type, there are the following possibilities for th
 
 - If the current release is a release candidate,
   - and you want to create another release candidate, use: `rc`. If the current release is e.g. v3.6.1-rc.0, this will bump the version to v3.6.1-rc.1.
-  - and the next release will not be, use: `drop-rc`. If the current release is e.g. v3.6.1-rc.0, this will bump the version to v3.6.1.
-  - and changes have been made since the previous release candidate that impact the release type, use: `rc-major`, `rc-minor`, or `rc-patch`. If the current release is e.g. v3.6.1-rc.0, using `rc-minor` will bump the version to v3.7.0-rc.0.
+  - and the next release will not be, use: `release`. If the current release is e.g. v3.6.1-rc.0, this will bump the version to v3.6.1.
+  - and changes have been made since the previous release candidate that impact the release type, use: `major`, `minor`, or `patch`. If the current release is e.g. v3.6.1-rc.0, using `minor` will bump the version to v3.7.0-rc.0.
 - If the current release is not a release candidate:
-  - and you want to create a release candidate, use: `rc-major`, `rc-minor`, or `rc-patch`. If the current release is e.g. v3.6.1, using `rc-minor` will bump the version to v3.7.0-rc.0.
-  - and you don't want to create a release candidate, use: `major`, `minor`, or `patch`. If the current release is e.g. v3.6.1, using `minor` will bump the version to v3.7.0.
+  - to create a release candidate, use: `major`, `minor`, or `patch`. If the current release is e.g. v3.6.1, using `minor` will bump the version to v3.7.0-rc.0.
 
 ### Check the preconditions
 
-The release script will check a number of preconditions before actually creating the release. To check the preconditions
-without releasing, invoke the release script with the version bump as determined:
+The release script will check a number of preconditions before actually creating the release.
+To check the preconditions without releasing, invoke the release script with the version bump as determined:
 
 ```console
-python release.py --check-preconditions-only <bump>  # Where bump is major, minor, patch, rc-major, rc-minor, rc-patch, rc, or drop-rc
+python release.py --check-preconditions-only <bump>  # Where bump is major, minor, patch, rc, or release
 ```
 
-If everything is ok, there is no output, and you can proceed creating the release. Otherwise, the release script will list the preconditions that have not been met and need fixing before you can create the release.
+If everything is ok, there is no output, and you can proceed creating the release.
+Otherwise, the release script will list the preconditions that have not been met and need fixing before you can create the release.
 
 ### Create the release
 
-To release *Quality-time*, issue the release command (in the release folder) using the type of release you picked:
+To release *Quality-time*, issue the release command (in the release folder) from an already created release candidate:
 
 ```console
-python release.py <bump>  # Where bump is major, minor, patch, rc-major, rc-minor, rc-patch, rc, or drop-rc
+python release.py release
 ```
 
-If all preconditions are met, the release script will bump the version numbers, update the change history, commit the changes, push the commit, tag the commit, and push the tag to GitHub. The [GitHub Actions release workflow](https://github.com/ICTU/quality-time/actions/workflows/release.yml) will then build the Docker images and push them to [Docker Hub](https://hub.docker.com/search?type=image&q=ictu/quality-time). It will also create an {index}`Software Bill of Materials (SBOM) <Software Bill of Materials (SBOM)>` for the release, which can be found under the "Artifacts" header of the workflow run.
+If all preconditions are met, the release script will bump the version numbers, update the change history, commit the changes, push the commit, tag the commit, and push the tag to GitHub.
+The [GitHub Actions release workflow](https://github.com/ICTU/quality-time/actions/workflows/release.yml) will then build the Docker images and push them to [Docker Hub](https://hub.docker.com/search?type=image&q=ictu/quality-time).
+It will also create an {index}`Software Bill of Materials (SBOM) <Software Bill of Materials (SBOM)>` for the release, which can be found under the "Artifacts" header of the workflow run.
 
 The Docker images are `quality-time_database`, `quality-time_renderer`, `quality-time_api_server`, `quality-time_collector`, `quality-time_notifier`, `quality-time_proxy`, `quality-time_testldap`, and `quality-time_frontend`. The images are tagged with the version number. We don't use the `latest` tag.