docs [installation]: Add the release process.

Add some indication on how to release single packages.
Update the development guidelines.

instructions/development.md

@@ -51,19 +51,48 @@ for the installed files to reflect the new changes.
 
 # Development guidelines
 
+Use English (prefer American English) when writing comments, identifiers (variables,
+functions, classes, etc.), and commit messages.
+
+Limit your lines length to 88 characters (enforced for the code by `black`, but try to
+respect it also in the docstring and text files).
+
+Do document your functions, classes and methods with some docstring.
+
+Try use python typing for your functions and methods arguments.
+
+``` python
+def append_suffix(string: str, suffix: str) -> str:
+    """Short description of the function.
+
+    Long description and details about the function.
+
+    Parameters
+    ----------
+    string
+        Description of the ``string`` parameter.
+    suffix
+        Description of the ``suffix`` parameter.
+
+    Returns
+    -------
+    Description of the return value.
+    """
+
+    return "".join((string, suffix))
+```
+
 Commit your changes to a branch (not main or master), and create merge requests (MR) in
 GitLab for your changes to be included into a package.
 
 Prefer the use of [Conventional Commit](https://www.conventionalcommits.org/en/v1.0.0/)
 to write your commit messages.
 
-Try to make commits atomic.
-
 Use `pre-commit` to ensure the code quality respects our standards. You will need to
 install the `pre-commit` package once in your environment, and run `pre-commit install`
 on a freshly cloned repository. If you already committed changes before installing,
 please run `pre-commit run --all-files` to verify that previous changes are up to
-standards.
+standards. The CI will fail if `pre-commit` does not pass.
 
 ``` sh
 conda activate your_dev_env
@@ -73,7 +102,7 @@ pre-commit install
 pre-commit run --all-files
 ```
 
-Then the `pre-commit` hooks will be called every time you do a `git commit`, with a nice
+Then the `pre-commit` hooks will be called every time you do a `git commit`, with a
 summary of what was modified automatically or what needs to be fixed. When everything is
 fixed, just run `git commit` again and (if everything is correct), the commit will not
 fail.
@@ -82,3 +111,77 @@ You can then `git push` your changes to GitLab and create a merge request with a
 description of the changes you made.
 
 A CI pipeline will then be run to ensure tests pass and the package can be built.
+
+# Releasing a bob package
+
+Once a package is passing the CI pipelines on the master branch the package is released
+as a beta both on the conda channel and its GitLab package registry.
+
+Before releasing the package, a few details must be taken care of:
+
+- Pin the conda dependencies versions in `conda/meta.yaml`;
+- Pin the dependencies versions in `pyproject.toml`;
+- Change the version number in `pyproject.toml`;
+- Generate/write a changelog;
+- Set a tag on the main GitLab branch with the changelog as description;
+- Run the CI pipeline for that tag.
+
+Most of these steps are automated in `idiap-devtools` and can be run with the commands:
+
+``` sh
+devtool gitlab changelog -o face_changelog.md bob/bob.bio.face
+devtool gitlab release face_changelog.md
+```
+
+Or to release multiple packages:
+
+``` sh
+echo bob/bob.bio.base > packages.txt
+echo bob/bob.bio.face >> packages.txt
+echo bob/bob.bio.video >> packages.txt
+devtool gitlab changelog -o mult_changelog.md ./packages.txt
+devtool gitlab release mult_changelog.md
+```
+
+## Versioning
+
+Follow [semantic versioning](https://semver.org/) when releasing bob packages.
+
+The version change type is defined in the changelog file output by
+`devtool gitlab changelog`. The default is `patch` and this can be changed for each
+package in the changelog:
+
+``` md
+# bob/bob.bio.face: patch
+
+  - bob/bob.bio.face!100: Fixed foo
+
+    Description of foo.
+
+  - bob/bob.bio.face!101: Solved bar
+```
+
+If the changes are more important, you can change `patch` to `minor` or `major` before
+calling `devtool gitlab release` on that changelog.
+
+```md
+# bob/bob.bio.face: major
+
+  - bob/bob.bio.face!102: Removed ham
+
+    BREAKING CHANGE: ham removed.
+
+  - bob.bob.bio.face!103: Modified spam
+
+    Description of changes.
+
+# bob/bob.bio.video: minor
+
+  - bob/bob.bio.video!100: Added baz
+```
+
+Once `devtool gitlab release` is called, each package in the changelog file will be
+edited to pin the version of the dependencies
+tagged on GitLab with the appropriate version and a CI pipeline will be run that
+publishes the new package on the main conda channel and on pypi. The command will wait
+for the previous package's pipeline to end before trying to release the next one.