Details about semver of the recipe

Spell out how we update the release versions of the recipe, specifically
wrt dependencies.
Based on the text of @dannygroenewegen.

MAINTENANCE.md

@@ -38,7 +38,7 @@ In order to meet these responsibilities each maintainer:
 ## Release cadence
 
 The intent is to **track Nextcloud's own release schedule** rather than invent
-our own. In practice this means:
+our own. In practice this means the following regarding new **nextcloud** releases:
 
 - **Patch releases (e.g. `32.0.x`)**: published to this recipe shortly after
   upstream, ideally within 1 week. `chore(deps)` opens the PRs; a maintainer
@@ -63,6 +63,34 @@ our own. In practice this means:
 - **Co-installed components** (Talk HPB, OnlyOffice, Whiteboard, etc.) are
   bumped alongside or shortly after the matching Nextcloud release.
 
+## Semver versioning within this recipe
+
+The recipe version itself is updated according to the following semver
+rules, following
+[How are recipes versioned](https://docs.coopcloud.tech/maintainers/handbook/#how-are-recipes-versioned):
+These describe the minimum required bump for a given kind of change. 
+The actual impact of any change (an image update or, e.g. a compose or config change) 
+should always be considered, and the recipe version can always be bumped higher 
+than the guideline below to match the impact of the change.
+ 
+- For updates of the image in the app container (nextcloud), we match the 
+  recipe version bump to at least the image version bump.
+- Other containers in this recipe are considered dependencies of the app container 
+  unless they expose additional functionality directly.
+- For image updates of dependency containers, we judge the recipe version bump 
+  from the perspective of the app itself, but a minor or major update of a 
+  dependent container is always reflected by at least a minor recipe version bump 
+  to indicate a substantial update under the hood.
+
+Temporary exception:
+- In the past, there have been issues with upgrades from database containers 
+  (before the `pgautoupgrade` image and `MARIADB_AUTO_UPGRADE` setting). 
+  We continue treating a major update of a database container (postgresql, mariadb) 
+  as a major recipe bump until that database has had two consecutive major upgrades 
+  with no issues reported, building trust in its automatic upgrade. 
+  Once that trust is established for a given database, we continue with the 
+  default guidelines above.
+
 ## Pull Requests
 
 A pull request can be merged once it is approved by at least one maintainer.