summary refs log tree commit diff
path: root/docs/message_retention_policies.md
diff options
context:
space:
mode:
authordevonh <devon.dmytro@gmail.com>2024-04-19 15:26:28 +0000
committerGitHub <noreply@github.com>2024-04-19 15:26:28 +0000
commit301c9771c41108218b0efab43f30982bf76dc349 (patch)
tree46711b8cf0275cebf66e3d161ef943b31f31071d /docs/message_retention_policies.md
parentBump types-pillow from 10.2.0.20240406 to 10.2.0.20240415 (#17090) (diff)
downloadsynapse-301c9771c41108218b0efab43f30982bf76dc349.tar.xz
Clarify what part of message retention is still experimental (#17099)
### Pull Request Checklist

<!-- Please read
https://element-hq.github.io/synapse/latest/development/contributing_guide.html
before submitting your pull request -->

* [X] Pull request is based on the develop branch
* [x] Pull request includes a [changelog
file](https://element-hq.github.io/synapse/latest/development/contributing_guide.html#changelog).
The entry should:
- Be a short description of your change which makes sense to users.
"Fixed a bug that prevented receiving messages from other servers."
instead of "Moved X method from `EventStore` to `EventWorkerStore`.".
  - Use markdown where necessary, mostly for `code blocks`.
  - End with either a period (.) or an exclamation mark (!).
  - Start with a capital letter.
- Feel free to credit yourself, by adding a sentence "Contributed by
@github_username." or "Contributed by [Your Name]." to the end of the
entry.
* [X] [Code
style](https://element-hq.github.io/synapse/latest/code_style.html) is
correct
(run the
[linters](https://element-hq.github.io/synapse/latest/development/contributing_guide.html#run-the-linters))
Diffstat (limited to '')
-rw-r--r--docs/message_retention_policies.md6
1 files changed, 4 insertions, 2 deletions
diff --git a/docs/message_retention_policies.md b/docs/message_retention_policies.md
index 2746a106b3..c64d1539b0 100644
--- a/docs/message_retention_policies.md
+++ b/docs/message_retention_policies.md
@@ -7,8 +7,10 @@ follow the semantics described in
 and allow server and room admins to configure how long messages should
 be kept in a homeserver's database before being purged from it.
 **Please note that, as this feature isn't part of the Matrix
-specification yet, this implementation is to be considered as
-experimental.**
+specification yet, the use of `m.room.retention` events for per-room
+retention policies is to be considered as experimental. However, the use
+of a default message retention policy is considered a stable feature
+in Synapse.**
 
 A message retention policy is mainly defined by its `max_lifetime`
 parameter, which defines how long a message can be kept around after