mirror of
https://github.com/element-hq/synapse.git
synced 2026-11-12 14:18:28 +00:00
Olivier 'reivilibre
1c79397d7f
After looking into it, just a couple of things to pick a bone at in the old wording, which I thought could be clarified for when I next come to look at this again. - the claim that there's a fundamental difference; I'd argue there isn't really, it's just by convention on some mainstream distros. So I have changed this to 'typically' - statements that some distros fetch dependencies at build time (probably does happen, but traditional distros make a point of not doing this for the reasons you'd expect). - This was probably meant to be talking about Debian, but my observation based on sample size of 3 is that some crates are packaged natively, others are vendored in the respective application's source package (like they do for us) and sometime they patch the bounds a bit There could probably be room to talk about how distros vendoring packages is a maintenance burden on them, but I guess it's a bit moot as we would struggle to conform to wide enough bounds to make everyone happy (and anyway; I expect the distros that vendor packages have the tooling to make this easy to update and we do keep on top of security updates and release frequently...) --- Spawning from discussion in [`#element-backend-internal:matrix.org`](https://matrix.to/#/!SGNQGPGUwtcPBUotTL:matrix.org/$VttYPPUevn2S_W_rrzg2ZOXWI6aKebk2ganTgrLEWUc?via=jki.re&via=element.io&via=matrix.org) --------- Signed-off-by: Olivier 'reivilibre <oliverw@matrix.org>
96 lines
4.8 KiB
Markdown
96 lines
4.8 KiB
Markdown
# Deprecation Policy
|
|
|
|
Synapse has a number of **platform dependencies** (Python, Rust, PostgreSQL, and SQLite)
|
|
and **application dependencies** (Python and Rust packages). This document outlines the
|
|
policy towards which versions we support, and when we drop support for versions in the
|
|
future.
|
|
|
|
## Platform Dependencies
|
|
|
|
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
|
|
version in future releases.
|
|
|
|
Details on the upstream support life cycles for Python and PostgreSQL are
|
|
documented at [https://endoflife.date/python](https://endoflife.date/python) and
|
|
[https://endoflife.date/postgresql](https://endoflife.date/postgresql).
|
|
|
|
A Rust compiler is required to build Synapse from source. For any given release
|
|
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](https://rustup.rs/)).
|
|
|
|
The oldest supported version of SQLite is the version
|
|
[provided](https://packages.debian.org/oldstable/libsqlite3-0) by
|
|
[Debian oldstable](https://wiki.debian.org/DebianOldStable) or the oldest maintenance/security-supported [Ubuntu LTS](https://endoflife.date/ubuntu) (Ubuntu versions with only Expanded Security Maintenance are not included).
|
|
|
|
|
|
### 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
|
|
effectively plan upgrading their infrastructure ahead of time. This is
|
|
especially important in contexts where upgrading the infrastructure requires
|
|
auditing and approval from a security team, or where otherwise upgrading is a
|
|
long process.
|
|
|
|
By following the upstream support life cycles Synapse can ensure that its
|
|
dependencies continue to get security patches, while not requiring system admins
|
|
to constantly update their platform dependencies to the latest versions.
|
|
|
|
For Rust, the situation is a bit different given that a) the Rust foundation
|
|
does not generally support older Rust versions, and b) the library ecosystem
|
|
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.
|
|
|
|
|
|
## Application dependencies
|
|
|
|
For application-level Python dependencies, we often specify loose version constraints
|
|
(ex. `>=X.Y.Z`) to be forwards compatible with any new versions. Upper bounds (`<A.B.C`)
|
|
are only added when necessary to prevent known incompatibilities.
|
|
|
|
When selecting a minimum version, while we are mindful of the impact on downstream
|
|
package maintainers, our primary focus is on the maintainability and progress of Synapse
|
|
itself.
|
|
|
|
For developers, a Python dependency version can be considered a "no-brainer" upgrade once it is
|
|
available in both the latest [Debian Stable](https://packages.debian.org/stable/) and
|
|
[Ubuntu LTS](https://launchpad.net/ubuntu) repositories. No need to burden yourself with
|
|
extra scrutiny or consideration at this point.
|
|
|
|
We aggressively update Rust dependencies. Since these are statically linked and managed
|
|
entirely by `cargo` during build, they *can* pose no ongoing maintenance burden on others.
|
|
This allows us to freely upgrade to leverage the latest ecosystem advancements assuming
|
|
they don't have their own system-level dependencies.
|
|
|
|
|
|
### Context
|
|
|
|
Because Python dependencies can easily be managed in a virtual environment, we are less
|
|
concerned about the criteria for selecting minimum versions. The only thing of concern
|
|
is making sure we're not making it unnecessarily difficult for downstream package
|
|
maintainers. Generally, this just means avoiding the bleeding edge for a few months.
|
|
|
|
The situation for Rust dependencies is typically different and
|
|
the concerns around Python dependency versions typically do not apply.
|
|
For example, for packagers of Debian, the packagers have the choice of either
|
|
using a crate packaged in the distro, or vendoring crates in the source package for the
|
|
application.
|
|
|
|
This freedom to vendor a dependency crate for a specific application consequently gives
|
|
us even greater flexibility to upgrade Rust dependencies as needed for the project.
|
|
|
|
(This is in contrast with Python dependencies, which are generally
|
|
installed system-wide by mainstream distributions' official packages.)
|
|
|
|
Some distros (e.g. Fedora) do not vendor Rust dependencies in their
|
|
official application packages, but these cases appear to be less common.
|