docs(CONTRIBUTING.md): add section on release management

CONTRIBUTING.md

@@ -33,6 +33,49 @@ Thus, before your contribution can be accepted by the project team, contributors
 For more information, please see the Eclipse Committer Handbook:
 https://www.eclipse.org/projects/handbook/#resources-commit
 
+## Release management
+
+`dart_wot` currently uses a semi-automated process for creating new releases.
+This involves generating the changelog, bumping the version number, and then
+letting GitHub Actions push the new version to pub.dev.
+
+### Changelog generation
+
+For the creation of the changelog, we use [`git-cliff`](https://git-cliff.org/)
+which automatically generates a `CHANGELOG.md` file based on the commit history
+and the [conventional commit](https://conventionalcommits.org) messages that
+have been used.
+The changelog is formatted according to the
+[Keep a Changelog](https://keepachangelog.com) format via the configuration
+options set in `cliff.toml`.
+
+Between releases, the changelog can be updated with a list of unreleased changes
+by using the following command:
+
+```sh
+  git cliff -o CHANGELOG.md
+```
+
+### Creating a new release
+
+Updating the changelog and preparing a new release is currently still involves
+some manual work.
+Once a new release is ready, run
+
+```sh
+  git cliff --bump -o CHANGELOG.md
+```
+
+to update the changelog and determine the new package version based on the
+type of changes that have been made so far.
+This version number then needs to be integrated into the `pubspec.yaml` file.
+After the changes have been committed to the `main` branch, a new git tag with
+the format `v[0-9]+.[0-9]+.[0-9]+*` that points to the latest commit has to be
+created.
+When the new tag is pushed to the remote repository on GitHub, a separate
+GitHub Actions workflow is then triggered that will push the new version to
+the pub.dev package repository.
+
 ## Contact
 
 Contact the project developers via the project's "dev" list.