diff --git a/develop/deprecation_policy.html b/develop/deprecation_policy.html index 3cae1c2ce2..e380dbf28d 100644 --- a/develop/deprecation_policy.html +++ b/develop/deprecation_policy.html @@ -147,9 +147,9 @@

Deprecation Policy for Platform Dependencies

-

Synapse has a number of platform dependencies, including Python and PostgreSQL. -This document outlines the policy towards which versions we support, and when we -drop support for versions in the future.

+

Synapse has a number of platform dependencies, including Python, Rust, +PostgreSQL and SQLite. This document outlines the policy towards which versions +we support, and when we drop support for versions in the future.

Policy

Synapse follows the upstream support life cycles for Python and PostgreSQL, i.e. when a version reaches End of Life Synapse will withdraw support for that @@ -161,6 +161,9 @@ documented at https://endoflife.date/pyt the minimum required version may be bumped up to a recent Rust version, and so people building from source should ensure they can fetch recent versions of Rust (e.g. by using rustup).

+

The oldest supported version of SQLite is the version +provided by +Debian oldstable.

Context

It is important for system admins to have a clear understanding of the platform requirements of Synapse and its deprecation policies so that they can @@ -177,6 +180,10 @@ generally bump their minimum support Rust versions frequently. In general, the Synapse team will try to avoid updating the dependency on Rust to the absolute latest version, but introducing a formal policy is hard given the constraints of the ecosystem.

+

On a similar note, SQLite does not generally have a concept of "supported +release"; bugfixes are published for the latest minor release only. We chose to +track Debian's oldstable as this is relatively conservative, predictably updated +and is consistent with the .deb packages released by Matrix.org.

diff --git a/develop/print.html b/develop/print.html index b5f030510a..fe7c076ff4 100644 --- a/develop/print.html +++ b/develop/print.html @@ -16795,9 +16795,9 @@ table. Each subject can have only one.

Stats correspond to the present values. Current rows contain the most up-to-date statistics for a room. Each subject can only have one entry.

Deprecation Policy for Platform Dependencies

-

Synapse has a number of platform dependencies, including Python and PostgreSQL. -This document outlines the policy towards which versions we support, and when we -drop support for versions in the future.

+

Synapse has a number of platform dependencies, including Python, Rust, +PostgreSQL and SQLite. This document outlines the policy towards which versions +we support, and when we drop support for versions in the future.

Policy

Synapse follows the upstream support life cycles for Python and PostgreSQL, i.e. when a version reaches End of Life Synapse will withdraw support for that @@ -16809,6 +16809,9 @@ documented at https://endoflife.date/pyt the minimum required version may be bumped up to a recent Rust version, and so people building from source should ensure they can fetch recent versions of Rust (e.g. by using rustup).

+

The oldest supported version of SQLite is the version +provided by +Debian oldstable.

Context

It is important for system admins to have a clear understanding of the platform requirements of Synapse and its deprecation policies so that they can @@ -16825,6 +16828,10 @@ generally bump their minimum support Rust versions frequently. In general, the Synapse team will try to avoid updating the dependency on Rust to the absolute latest version, but introducing a formal policy is hard given the constraints of the ecosystem.

+

On a similar note, SQLite does not generally have a concept of "supported +release"; bugfixes are published for the latest minor release only. We chose to +track Debian's oldstable as this is relatively conservative, predictably updated +and is consistent with the .deb packages released by Matrix.org.

Summary of performance impact of running on resource constrained devices such as SBCs

I've been running my homeserver on a cubietruck at home now for some time and am often replying to statements like "you need loads of ram to join large rooms" with "it works fine for me". I thought it might be useful to curate a summary of the issues you're likely to run into to help as a scaling-down guide, maybe highlight these for development work or end up as documentation. It seems that once you get up to about 4x1.5GHz arm64 4GiB these issues are no longer a problem.