global release docs

RELEASE.md

@@ -12,7 +12,6 @@ Things to take into account while writing a changelog:
  - Breaking changes.
  - Notable changes.
 
-
 ## Release Process
 
 Try to constrain each development cycle to a fixed time period, after which a
@@ -35,18 +34,19 @@ Usually the release process is as follows:
 5. Create a new tag for the release branch.
 6. Publish the release.
 
-
 ## Versioning
 
-Protocol and Utils crates follow SemVer 2.0.0. The version number is stored in
+Crates under `protocols` and `utils` workspaces follow SemVer 2.0.0. The version number is stored in
 the `Cargo.toml` file of each crate. If a breaking change is introduced to one
 of the crates, the version number must be updated accordingly, otherwise a
 SemVer CI check would fail. Note that this does not apply to the `roles` and
 other crates in the repository.
 
-The general SRI version does not follow any SemVer rules. You can track the
-releases on Github Releases in the repository.
-
+The global repository releases follow `X.Y.Z`, which is changed under some subjective criteria:
+- any changes to `roles` are not taken into account, as to signify that they are mere PoCs are not suited for production scenarios.
+- if the release is **only** fixing bugs on `protocols` or `utils`, then `Z` is bumped.
+- if the release is applying changes (breaking or non-breaking, which could also fix some bugs) to `protocols` or `utils`, then `Y` is bumped.
+- if the release marks a milestone where `protocols` is reaching a new level of maturity, then `X` is bumped.
 
 ## Tags and Branches