diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 71f1f27cb84deb0d43b0a4f598e2b92730729c23..5af099a99145ddc9cffe81ba447982e146927b43 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -7,7 +7,7 @@ before_script:
   - source venv/bin/activate
 
 # Run the test suite using tox.
-# This job is called when commits are pushed to the main branch,
+# 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).
 test:
   script:
@@ -15,14 +15,16 @@ test:
     - tox -e py38
   rules:
     - if: ($CI_COMMIT_BRANCH == "main") && ($CI_PIPELINE_SOURCE == "push")
-          && ($CI_COMMIT_TITLE !~ /^Merge branch '.*' into main/)
+          && ($CI_COMMIT_TITLE !~ /^Merge branch '.*' into 'main'/)
+    - if: ($CI_COMMIT_BRANCH == "develop") && ($CI_PIPELINE_SOURCE == "push")
+          && ($CI_COMMIT_TITLE !~ /^Merge branch '.*' into 'develop'/)
   tags:
     - ci.inria.fr
     - small
 
 # Run the test suite using tox, with --fulltest option.
 # This job is called on creation and pushes to non-Draft MRs.
-# It may also be launched manually upon pushes to Draft MRs or main branch.
+# It may also be launched manually upon pushes to Draft MRs or main/dev branch.
 test-full:
   script:
     - pip install -U tox
@@ -33,7 +35,8 @@ test-full:
     - if: ($CI_PIPELINE_SOURCE == "merge_request_event")
           && ($CI_MERGE_REQUEST_TITLE =~ /^Draft:.*/)
       when: manual
-    - if: ($CI_COMMIT_BRANCH == "main") && ($CI_PIPELINE_SOURCE == "push")
+    - if: (($CI_COMMIT_BRANCH == "main") || ($CI_COMMIT_BRANCH == "develop"))
+          && ($CI_PIPELINE_SOURCE == "push")
       when: manual
   tags:
     - ci.inria.fr
diff --git a/README.md b/README.md
index 52763e4321486be6103317ecebcad476935588d3..79f103078166eee32305da4ebf2c7d083a81e3d8 100644
--- a/README.md
+++ b/README.md
@@ -699,7 +699,24 @@ forward framework evolutions and API revisions.
 
 To contribute directly to the code (beyond posting issues on gitlab), please
 create a dedicated branch, and submit a **Merge Request** once you want your
-work reviewed and further processed to end up integrated into the main branch.
+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
+  a feature into multiple branches that will incrementally be merged into an
+  intermediate feature branch that will eventually be merged into 'develop'
 
 The **coding rules** are fairly simple:
 
@@ -721,6 +738,10 @@ The **coding rules** are fairly simple:
 - 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
+  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
 
 ### Unit tests and code analysis