|
| 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