This document describes how we decide which minimum versions of operating systems, C++ standards, libraries, build tools (CMake) or compilers Minetest requires.
Most important is that we do not increase our minimum requirements without a reason or use case. A reason can be as simple as "cleaning up legacy support code", but it needs to exist.
As most development happens on Linux the first measure is to check the version of the component in question on:
Generally this leads to versions about 5 years old and works as a reasonable result for BSDs and other platforms too.
Needless to say that any new requirements need to work on our other platforms too, as listed below.
We currently support Windows 8 or later.
Despite requiring explicit support code in numerous places there doesn't seem to be a strong case for dropping older Windows versions. We will likely only do it once SDL2 does so.
Note that we're constrained by the versions vcpkg offers, for the MSVC build.
We currently support macOS 10.14 (Mojave) or later.
Since we do not have any macOS developer we can only do some shallow testing in CI. So this is subject to change basically whenever Github throws a new version at us, or for other reasons.
We currently support Android 5.0 (API 21) or later.
There's usually no reason to raise this unless the NDK drops older versions.
Note: You can check the Google Play Console to see what our user base is running.
Compilers: gcc, clang and MSVC (exceptions exist)
OpenGL is an entirely different beast, there is no formal consensus on changing the requirements and neither do we have an exact set of requirements.
We still support OpenGL 1.4 without shaders (fixed-pipeline), which could be considered very unreasonable in 2024. OpenGL ES 2.0 is supported for the sake of mobile platforms.
It has been proposed moving to OpenGL 2.x or 3.0 with shaders required.
General system requirements are not bounded either. Being able to play Minetest on a recent low-end phone is a reasonable target.
These rules are not absolute and there can be exceptions.
But consider how much trouble it would be to chase down a new version of a component on an old distro:
The rules can be seen more relaxed for optional dependencies, but remember to be reasonable. Sound is optional at build-time but nobody would call an engine build without sound complete.
In general also consider:
The SpatialIndex support is a good example for the latter. It is only used to speed up some (relatively unimportant) API feature, but there's no loss of functionality if you don't have it.
(as of April 2024)
Situation: someone wants C++20 to use std::span
MSVC supports it after some version, should be fine as long as it builds in CI
gcc with libstdc++ 10 or later
clang with libc++ 7 or later (note: no mainstream Linux distros use this)
Debian 11 has libstdc++ 10
Ubuntu 20.04 LTS has libstdc++ 9
(optional) Rocky Linux 8 has libstdc++ 8
Windows, Android and macOS are probably okay
Verdict: not possible. maybe next year.
Possible alternative: use a library that provides a polyfill for std::span