Skip to content

Commit 98fd5bd

Browse files
authored
Formalize OS support policy (luanti-org#14556)
1 parent 15b569f commit 98fd5bd

File tree

2 files changed

+110
-0
lines changed

2 files changed

+110
-0
lines changed

doc/developing/README.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -16,6 +16,7 @@ Notable pages:
1616

1717
- [Developing minetestserver with Docker](docker.md)
1818
- [Android tips & tricks](android.md)
19+
- [OS/library compatibility policy](os-compatibility.md)
1920
- [Miscellaneous](misc.md)
2021

2122
## IRC

doc/developing/os-compatibility.md

Lines changed: 109 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,109 @@
1+
OS/library compatibility policy
2+
===============================
3+
4+
This document describes how we decide which minimum versions of operating systems, C++ standards,
5+
libraries, build tools (CMake) or compilers Minetest requires.
6+
7+
Most important is that we do not increase our minimum requirements without a reason or use case.
8+
A reason can be as simple as "cleaning up legacy support code", but it needs to exist.
9+
10+
As most development happens on Linux the first measure is to check the version of the component in question on:
11+
* the oldest still-supported **Ubuntu** (End of Standard Support)
12+
* the oldest still-supported **Debian** (*not* LTS)
13+
* optional: the second newest **RHEL (derivative)**
14+
15+
Generally this leads to versions about 5 years old and works as a reasonable result for BSDs and other platforms too.
16+
17+
Needless to say that any new requirements need to work on our other platforms too, as listed below.
18+
19+
### Windows
20+
21+
We currently support Windows 8 or later.
22+
23+
Despite requiring explicit support code in numerous places there doesn't seem to be a strong case
24+
for dropping older Windows versions. We will likely only do it once SDL2 does so.
25+
26+
Note that we're constrained by the versions [vcpkg](https://vcpkg.io/en/packages) offers, for the MSVC build.
27+
28+
### macOS
29+
30+
We currently support macOS 10.14 (Mojave) or later.
31+
32+
Since we do not have any macOS developer we can only do some shallow testing in CI.
33+
So this is subject to change basically whenever Github throws
34+
[a new version](https://github.com/actions/runner-images?tab=readme-ov-file#available-images) at us, or for other reasons.
35+
36+
### Android
37+
38+
We currently support Android 5.0 (API 21) or later.
39+
40+
There's usually no reason to raise this unless the NDK drops older versions.
41+
42+
*Note*: You can check the Google Play Console to see what our user base is running.
43+
44+
## Other parts
45+
46+
**Compilers**: gcc, clang and MSVC (exceptions exist)
47+
48+
**OpenGL** is an entirely different beast, there is no formal consensus on changing the requirements
49+
and neither do we have an exact set of requirements.
50+
51+
We still support OpenGL 1.4 without shaders (fixed-pipeline), which could be considered very unreasonable in 2024.
52+
OpenGL ES 2.0 is supported for the sake of mobile platforms.
53+
54+
It has been [proposed](https://irc.minetest.net/minetest-dev/2022-08-18) moving to OpenGL 2.x or 3.0 with shaders required.
55+
56+
General **system requirements** are not bounded either.
57+
Being able to play Minetest on a recent low-end phone is a reasonable target.
58+
59+
## On totality
60+
61+
These rules are not absolute and there can be exceptions.
62+
63+
But consider how much trouble it would be to chase down a new version of a component on an old distro:
64+
* C++ standard library: probably impossible without breaking your system(?)
65+
* compiler: very annoying
66+
* CMake: somewhat annoying
67+
* some ordinary library: reasonably easy
68+
69+
The rules can be seen more relaxed for optional dependencies, but remember to be reasonable.
70+
Sound is optional at build-time but nobody would call an engine build without sound complete.
71+
72+
In general also consider:
73+
* Is the proposition important enough to warrant a new dependency?
74+
* Can we make it easier for users to build the library together with Minetest?
75+
* Maybe even vendor the library?
76+
* Or could the engine include a transparent fallback implementation?
77+
78+
The SpatialIndex support is a good example for the latter. It is only used to speed up some (relatively unimportant)
79+
API feature, but there's no loss of functionality if you don't have it.
80+
81+
## A concrete example
82+
83+
(as of April 2024)
84+
85+
```
86+
Situation: someone wants C++20 to use std::span
87+
88+
MSVC supports it after some version, should be fine as long as it builds in CI
89+
gcc with libstdc++ 10 or later
90+
clang with libc++ 7 or later (note: no mainstream Linux distros use this)
91+
92+
Debian 11 has libstdc++ 10
93+
Ubuntu 20.04 LTS has libstdc++ 9
94+
(optional) Rocky Linux 8 has libstdc++ 8
95+
Windows, Android and macOS are probably okay
96+
97+
Verdict: not possible. maybe next year.
98+
99+
Possible alternative: use a library that provides a polyfill for std::span
100+
```
101+
102+
## Links
103+
104+
* Ubuntu support table: https://wiki.ubuntu.com/Releases
105+
* Debian support table: https://wiki.debian.org/LTS
106+
* Release table of a RHEL derivative: https://en.wikipedia.org/wiki/AlmaLinux#Releases
107+
* Android API levels: https://apilevels.com/
108+
* C++ standard support information: https://en.cppreference.com/w/cpp/compiler_support
109+
* Distribution-independent package search: https://repology.org/ or https://pkgs.org/

0 commit comments

Comments
 (0)