Olivier 'reivilibreandGitHub
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>
4.8 KiB
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 and 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).
The oldest supported version of SQLite is the version provided by Debian oldstable or the oldest maintenance/security-supported Ubuntu LTS (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 and Ubuntu LTS 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.