diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 5af099a99145ddc9cffe81ba447982e146927b43..fe44062ad77f0e077ad3329c8ddfec727ffea0fb 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -7,17 +7,14 @@ before_script:
   - source venv/bin/activate
 
 # Run the test suite using tox.
-# This job is called when commits are pushed to the main or the dev branch,
-# save for merge-resulting commits (that are expected to come from MRs).
+# This job is called when commits are pushed to the main or a release branch.
 test:
   script:
     - pip install -U tox
     - tox -e py38
   rules:
-    - if: ($CI_COMMIT_BRANCH == "main") && ($CI_PIPELINE_SOURCE == "push")
-          && ($CI_COMMIT_TITLE !~ /^Merge branch '.*' into 'main'/)
-    - if: ($CI_COMMIT_BRANCH == "develop") && ($CI_PIPELINE_SOURCE == "push")
-          && ($CI_COMMIT_TITLE !~ /^Merge branch '.*' into 'develop'/)
+    - if: ($CI_PIPELINE_SOURCE == "push") &&
+          (($CI_COMMIT_BRANCH == "develop") || ($CI_COMMIT_BRANCH =~ "/^r\d\.\d+/"))
   tags:
     - ci.inria.fr
     - small
@@ -30,13 +27,13 @@ test-full:
     - pip install -U tox
     - tox -e py38 -- --fulltest
   rules:
-    - if: ($CI_PIPELINE_SOURCE == "merge_request_event")
-          && ($CI_MERGE_REQUEST_TITLE !~ /^Draft:.*/)
-    - if: ($CI_PIPELINE_SOURCE == "merge_request_event")
-          && ($CI_MERGE_REQUEST_TITLE =~ /^Draft:.*/)
+    - if: ($CI_PIPELINE_SOURCE == "merge_request_event") &&
+          ($CI_MERGE_REQUEST_TITLE !~ /^Draft:.*/)
+    - if: ($CI_PIPELINE_SOURCE == "merge_request_event") &&
+          ($CI_MERGE_REQUEST_TITLE =~ /^Draft:.*/)
       when: manual
-    - if: (($CI_COMMIT_BRANCH == "main") || ($CI_COMMIT_BRANCH == "develop"))
-          && ($CI_PIPELINE_SOURCE == "push")
+    - if: ($CI_PIPELINE_SOURCE == "push") &&
+          (($CI_COMMIT_BRANCH == "develop") || ($CI_COMMIT_BRANCH =~ "/^r\d\.\d+/"))
       when: manual
   tags:
     - ci.inria.fr
diff --git a/README.md b/README.md
index 3ab040e8d80bf7b0afe2d1ede39701bdba70ea97..592a2d8833f49abf31b35a27b65b7107531a77c3 100644
--- a/README.md
+++ b/README.md
@@ -229,27 +229,27 @@ client.run()
 
 ### Support for GPU acceleration
 
-TL;DR: GPU acceleration is natively available in `declearn` for model 
-frameworks that support it, with one line of code and without changing 
+TL;DR: GPU acceleration is natively available in `declearn` for model
+frameworks that support it, with one line of code and without changing
 your original model.
 
 Details:
 
-Most machine learning frameworks, including Tensorflow and Torch, enable 
-accelerating computations by using computational devices other than CPU. 
-`declearn` interfaces supported frameworks to be able to set a device policy 
-in a single line of code, accross frameworks. 
+Most machine learning frameworks, including Tensorflow and Torch, enable
+accelerating computations by using computational devices other than CPU.
+`declearn` interfaces supported frameworks to be able to set a device policy
+in a single line of code, accross frameworks.
 
 `declearn` internalizes the framework-specific code adaptations to place the
-data, model weights and computations on such a device. `declearn` provides 
-with a simple API to define a global device policy. This enables using a 
-single GPU to accelerate computations, or forcing the use of a CPU. 
+data, model weights and computations on such a device. `declearn` provides
+with a simple API to define a global device policy. This enables using a
+single GPU to accelerate computations, or forcing the use of a CPU.
 
-By default, the policy is set to use the first available GPU, and otherwise 
+By default, the policy is set to use the first available GPU, and otherwise
 use the CPU, with a warning that can safely be ignored.
 
-Setting the device policy to be used can be done in local scripts, either as a 
-client or as a server. Device policy is local and is not synchronized between 
+Setting the device policy to be used can be done in local scripts, either as a
+client or as a server. Device policy is local and is not synchronized between
 federated learninng participants.
 
 Here are some examples of the one-liner used:
@@ -737,45 +737,45 @@ work reviewed and further processed to end up integrated into the package.
 
 The **git branching strategy** is the following:
 
-- 'main' matches the latest release's X.Y version, but may hold unreleased
-  patch changes; i.e. it can be seen as version X.Y.(Z+1)-beta
-- 'develop' holds finalized changes that should be made part of the next
-  minor version release; i.e. it can be seen as version X.(Y+1).0-beta
-- when necessary, intermediate release branches may be set up to cherry-pick
-  changes from 'develop' to be included in a given minor version release
-- 'main', 'develop' and any intermediate release branch are expected to be
-  stable at all times
-- feature branches should be created at will to develop features, enhancements,
-  or even hotfixes that will later be merged into 'develop' and eventually into
-  'main'.
-- it is legit to write up poc branches, as well as to split the development of
+- The 'develop' branch is the main one and should receive all finalized changes
+  to the source code. Release branches are then created and updated by cherry-
+  picking from that branch. It therefore acts as a nightly stable version.
+- The 'rX.Y' branches are release branches for each and every X.Y versions.
+  For past versions, these branches enable pushing patches towards a subminor
+  version release (hence being version `X.Y.(Z+1)-dev`). For future versions,
+  these branches enable cherry-picking commits from main to build up an alpha,
+  beta, release-candidate and eventually stable `X.Y.0` version to release.
+- Feature branches should be created at will to develop features, enhancements,
+  or even hotfixes that will later be merged into 'main' and eventually into
+  one or multiple release branches.
+- It is legit to write up poc branches, as well as to split the development of
   a feature into multiple branches that will incrementally be merged into an
-  intermediate feature branch that will eventually be merged into 'develop'
+  intermediate feature branch that will eventually be merged into 'main'.
 
 The **coding rules** are fairly simple:
 
-- abide by [PEP 8](https://peps.python.org/pep-0008/), in a way that is
-  coherent with the practices already at work in declearn
-- abide by [PEP 257](https://peps.python.org/pep-0257/), _i.e._ write
+- Abide by [PEP 8](https://peps.python.org/pep-0008/), in a way that is
+  coherent with the practices already at work in declearn.
+- Abide by [PEP 257](https://peps.python.org/pep-0257/), _i.e._ write
   docstrings **everywhere** (unless inheriting from a method, the behaviour
   and signature of which are unmodified), again using formatting that is
-  coherent with the declearn practices
-- type-hint the code, abiding by [PEP 484](https://peps.python.org/pep-0484/);
+  coherent with the declearn practices.
+- Type-hint the code, abiding by [PEP 484](https://peps.python.org/pep-0484/);
   note that the use of Any and of "type: ignore" comments is authorized, but
-  should be remain sparse
-- lint your code with [mypy](http://mypy-lang.org/) (for static type checking)
+  should be remain sparse.
+- Lint your code with [mypy](http://mypy-lang.org/) (for static type checking)
   and [pylint](https://pylint.pycqa.org/en/latest/) (for more general linting);
   do use "type: ..." and "pylint: disable=..." comments where you think it
-  relevant, preferably with some side explanations
+  relevant, preferably with some side explanations.
   (see dedicated sub-sections below: [pylint](#running-pylint-to-check-the-code)
   and [mypy](#running-mypy-to-type-check-the-code))
-- reformat your code using [black](https://github.com/psf/black); do use
+- Reformat your code using [black](https://github.com/psf/black); do use
   (sparingly) "fmt: off/on" comments when you think it relevant
-  (see dedicated sub-section [below](#running-black-to-format-the-code))
-- abide by [semver](https://semver.org/) when implementing new features or
+  (see dedicated sub-section [below](#running-black-to-format-the-code)).
+- Abide by [semver](https://semver.org/) when implementing new features or
   changing the existing APIs; try making changes non-breaking, document and
   warn about deprecations or behavior changes, or make a point for API-breaking
-  changes, which we are happy to consider but might take time to be released
+  changes, which we are happy to consider but might take time to be released.
 
 ### Unit tests and code analysis